New in IPv6: Stable Random IPv6 Addresses on OpenBSD

The idea of generating random IPv6 addresses (so you cannot be tracked across multiple networks based on your MAC address) that stay stable within each subnet (so you don’t pollute everyone’s ND cache every time you open your iPad) is pretty old: RFC 7217 was published almost exactly four years ago.

Linux was quick to pick it up, OpenBSD got RFC 7127 support a few weeks ago. However, there’s an Easter egg in the OpenBSD patches that implement it: SLAAC on OpenBSD now works with any prefix length (not just /64).

Turns out there never was a requirement to have /64 prefixes to use SLAAC before RFC 4291 was published (RFC 4291 specifies the length of interface identifiers to be 64 bits)… or so Peter Hessler claimed during a Troopers dinner. Disagree? Please write a comment!

New to IPv6?

I decided I won’t spend any more time on a protocol that is old enough to buy its own beer, but the IPv6 webinars on ipSpace.net are still pretty relevant (yeah, nothing much has changed in the meantime).

Recent posts in the same categories

14 comments:

  1. Anonymous 03 April 2018 12:21
    And how about tracking which host got which IPv6 address with SLAAC? That would be the more interesting problem to solve.
    Replies
    1. Ivan Pepelnjak 03 April 2018 13:24
      The only viable solution for this problem (I've seen so far) is to periodically inspect ND caches on first-hop routers.
  2. Ben Kinsella 03 April 2018 13:09
    I'm confused. RFC 2464 (https://tools.ietf.org/html/rfc2464: Transmission of IPv6 Packets over Ethernet Networks) specifically states:
    An IPv6 address prefix used for stateless autoconfiguration [ACONF]
    of an Ethernet interface must have a length of 64 bits.
    Replies
    1. Ivan Pepelnjak 03 April 2018 13:23
      And this was exactly what I was looking for. Thanks a million!
    2. Robert Parten 03 April 2018 18:08
      Yeah, I mean you CAN do it, but you'll find things will break and behave oddly when decide against using /64 subnets. I experimented with this, and I think I even blogged about it, because I had to fight with people internal to a company I worked for about why subnetting any further wouldn't work, especially since we were using Stateful DHCPv6 :-/
    3. Ivan Pepelnjak 03 April 2018 18:17
      I was told things mostly work on non-64 subnets (amazing in itself) as long as you don't use SLAAC. There is, however, the "small" detail that most forwarding hardware has limited number of forwarding entries for prefixes longer than /64.

      Why would you ever want to use it? Beats me... Seems more like proving a point to me.
    4. Anonymous 03 April 2018 19:08
      But 2464 was formally updated by 8064 which recommends to use 7217 for generating iid. Thus prefix different than /64 should be fine. There's however 4291 (addressing architecture) that states that All Global Unicast addresses have a 64-bit interface ID field. Add a neverending fight in ietf for 4291-bis (should addressing architecture require such a constraint?) and you end up with a mess. Like everything in ipv6 :)
  3. Toby Skandier 03 April 2018 15:07
    RFC 8064 does a nice job of wrangling related RFCs, such as 7217.
    Replies
    1. Ivan Pepelnjak 03 April 2018 15:13
      One of the more obvious artifacts of the IETF process. It should be a no-brainer to use the technology that incorporates lessons learned from past mistakes... but we need an RFC to say "you should really really really use this other RFC" ;))
    2. Unknown 03 April 2018 15:47
      It really SHOULD be a no brainer, and it ends more like hoping that you have found all related RFCs. I was trying to write about generating stable random IPv6 addresses ( here ) and got a ton of e-mails giving me more and more RFCs to correct my first try :) We went all the way from 2373 to 4291 to 4941 and finally to 8064.
  4. Robert Parten 03 April 2018 18:05
    Why would anyone want to use anything other than a /64 for end-hosts? It is not like we're trying not to exhaust an address scheme which could hand out an IPv6 address for each grain of sand on Earth, so why would anyone want to make their life more miserable than it, sometimes, is when managing networks?

    Perhaps I am not seeing the "other side" of why someone would use something other than a /64 for an IPv6 subnet for end-host addresses? Now, back to main topic, RFC7217 is pretty cool in and of itself from a security perspective
    Replies
    1. Ivan Pepelnjak 03 April 2018 18:21
      "Why would anyone want to use anything other than a /64 for end-hosts?" << still haven't found a good use case.

      Maybe "I need more segments but my provider is only giving me a /64" or "I want to do tethering but can't get more than a single /64 on LTE" or something similar? There's IA_PD, but then some people are still religiously opposed to DHCPv6 ;)
    2. Unknown 10 April 2018 14:52
      "Why would anyone want to use anything other than a /64 for end-hosts?" << still haven't found a good use case.

      Or, as seen in the IPv6 address concept of a large Swiss university network: /64 are reserved but not configured. Only /115 or /118 are configured.

      Although they do not use SLAAC, in terms of passive security, this is a neat trick to harden the network against resource exhaustion (simple reconnaissance by scanners, targeted DDoS attacks, etc.

      So the Easter egg in OpenBSD's SLAAC comes in handy in such networks
      :-)
    3. Ivan Pepelnjak 10 April 2018 18:50
      So they use DHCPv6 on the /115../118? Also wonder how well that plays with their switches...
Add comment
Home
Sidebar