BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.hackglasgow.live//hack-glasgow-2026//talk//7AYQR
 W
BEGIN:VTIMEZONE
TZID:GMT
BEGIN:STANDARD
DTSTART:20001029T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:GMT
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:BST
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-hack-glasgow-2026-7AYQRW@pretalx.hackglasgow.live
DTSTART;TZID=GMT:20260815T103000
DTEND;TZID=GMT:20260815T112500
DESCRIPTION:After six long years\, I've submitted my PhD thesis thesis on '
 Strategies for Scanning the IPv6 Address Space'. I'd love to share a few h
 ighlights of stuff I've learnt in that time\, focusing on these themes:\n\
 n - 'Ethical scanning of IPv6 scanning is difficult (but important!)': a s
 hort tour of my experimental setup I used to run IPv6 scans (rough around 
 the edges\, but lovingly crafted)\, and a few papers which were very impor
 tant to my work over the past few years. Very happy to bring my printed co
 pies of these to the talk as props\, they're covered in all sorts of post-
 it notes and handwritten notes at this point.\n - 'Rate-limiting is vital'
 : sounds like obvious advice\, but IPv6 defences are often not up to the s
 tandard of IPv4. Rate-limiting at the recipient end of unsolicited IPv6 sc
 ans does a lot to limit reconnaissance - it's no longer enough to assume w
 e're safe because it's a large address space\, it's a niche protocol\, we 
 have network address translation (NAT)\, etc. I have some scans that show 
 how we can detect rate-limiting thresholds and address allocation patterns
  in different networks with no prior info.\n - 'IoT devices are IPv6 capab
 le\, but at what cost?': this is a more detailed look at one of the papers
  in the first section ('One Bad Apple Can Spoil Your IPv6 Privacy' - Saidi
  et al.\, 2022)\, plus additional work I did for address analysis (and\, h
 opefully\, some actual IoT scans). IPv6-enabled IoT devices can be a hazar
 d in terms of user privacy from IPv6 addresses alone - some big name brand
 s still embed MAC addresses in public IPv6 addresses\, which can be used t
 o track users across different networks even if every other device on thei
 r network uses IPv6 privacy addresses.\n - 'One loudmouth can expose the e
 ntire operation': this section is original work\, building on the previous
  section. An unexpected side-effect of insecure MAC-derived IPv6 addresses
  is that a single sign-in attempt from a suspected IoT IPv6 address can re
 veal botnet-like sign-in activity - we can use info from this one sign-in 
 attempt to see many other IPv4 and IPv6 addresses attempting similar sign-
 ins across large numbers of accounts.\n - 'IPv6 should be part of the blue
  team toolbox': it's no longer a niche\, hobbyist protocol\, (un)fortunate
 ly - it's really important for fellow blue teamers to understand that mali
 cious behaviour is happening over IPv6\, how to analyse it in logs\, and h
 ow to handle IPv6 IoCs effectively. It might also be useful for red teamer
 s to know there's probably gaps in the IPv6 fence...\n - 'Conclusions': IP
 v6 scans are hard to run\, but there's a lot of us doing them. IPv6 is sti
 ll not implemented securely in IoT devices\, which has positives and negat
 ives. Evil over IPv6 is no longer theoretical and needs to be defended aga
 inst.
DTSTAMP:20260716T192220Z
LOCATION:Stage 2
SUMMARY:Six Years of IPv6 - Vi
URL:https://pretalx.hackglasgow.live/hack-glasgow-2026/talk/7AYQRW/
END:VEVENT
END:VCALENDAR