[ipv6hackers] Pros and Cons of Address Randomization

[Jim Small]

Hi Mark,

> >>  > Maybe this is an enterprise bias but my experience has been that
> >>  loopbacks (at least with IPv4) are numbered sequentially with predictable
> >>  patterns for ease of use.  These can be protected with ACLs/firewalls.  I
> >>  would like to do something similar for IPv6.  Maybe this is legacy thinking
> > but
> >>  I would dread giving this up and completely depending on DNS.  What
> about
> >>  outages where you're using an Out Of Band network and DNS is
> >>  down/unavailable?  This one would be hard for me...
> >>  >
> >>  You certainly can do something similar for IPv6 and I would actually
> > generally
> >>  advocate doing so. I just wouldn't start from ::1 in most cases.
> >
> > So where would you start at?  ::1001?  It's not that you memorize addresses
> > - I agree that's silly.  However when you use tools, simple patterned
> > numbers make life easier.  Granted you can have lists of addresses to
> march
> > through but it's the little things...  Especially when you're doing
> > something to 100s of routers/switches - spot checking patterned numbers
> is a
> > little easier than randomized addresses.  Maybe I'm just a little lazy.  :-)
> >
> 
> For network management, I think it'd be better just to use ULAs, as they're
> not accessible from the Internet. Once you do that, you can then use ::1, ::2,
> ::3 etc. on loopbacks without anywhere near as much risk.

I like this idea.  I can't think of why you'd want your loopbacks accessible from off-network even for eBGP speakers.  Just generate your randomized /48 ULA and start from ::1 with no worries about Internet scans (assuming proper ingress/egress filtering).

> More generally, I think one of the issues that makes these sorts of
> discussions more complex is the default assumption of global reachability of
> the nodes with the randomised or non-randomised addresses, and perhaps
> an assumption that the nodes will only have one address. As IPv6 fully
> supports multiple concurrent addresses, one option is to use randomised
> addresses for addresses where they're more valuable (i.e. globals), and non-
> random where they're less valuable or would create additional complexity
> (i.e. ULAs).

Makes sense.
 
> Perhaps there needs to be an "R" bit added to the RA PIO option that
> indicates that IIDs that are used within the specified prefix are to be
> randomised. This would be independent of the A bit, and would be used by
> what ever address configuration mechanism used to configure addresses
> within the prefix (e.g. currently SLAAC, possibly others in the future). That
> would make it possible to have randomised GUAs and non-randomised ULA
> addresses within a subnet.

This is an interesting idea.  I especially like it if it would use the logic Fernando proposed:
http://tools.ietf.org/html/draft-ietf-6man-stable-privacy-addresses-01

So it could use the above for SLAAC and for DHCPv6 perhaps it could also be used as a hint - if the R-bit is set, the client notifies the DHCPv6 server via some option that it wants a randomized IID.

--Jim