Re: Question about IPAM tools for v6

[Nick Hilliard]

 /64 netmask opens up nd cache exhaustion as a DoS vector.
 
 FUD.

I probably should have qualified this statement a little better before
posting it.

Large locally-connected connected l2 domains can open up nd cache
exhaustion and many other problems as DoS vectors if the operating systems
connected to these domains do not have resource exhaustion limitations
built in, or they are built in but not configured properly.

In particular, the large address space prevents operating systems from
implementing certain types of mitigation mechanisms that might be possible
with ipv4 (e.g. slot based rate limiting).  The ND rate limiters that I've
tested all cause collateral connectivity problems as they place all ND
floods from all hosts in the same RL bucket.

While some aspects of this problem are more generic and not specifically
related to the address domain size (i.e. they're similar to what's already
seen on ipv4), the fact that the addressing domain is so large does not
help either the o/s implementer or the operator and the issues relating to
ND flooding of whatever sort (NS/RA/etc) are something that explicitly need
to be understood by both the o/s implementer and the network operator
because otherwise connectivity problems can occur in production.

Nick

Re: Question on DHCPv6 address assignment

[Brian E Carpenter]

It's also worth noting that the old presumption that MAC-based
interface identifiers are normal and anything else is strange is
obsolete. See http://tools.ietf.org/html/draft-ietf-6man-ug-06
which is approved in the RFC queue already and
http://tools.ietf.org/html/draft-ietf-6man-default-iids-00
for a possible future recommendation.

These documents are mainly written with SLAAC in mind rather
than DHCPv6, but I don't think that changes the principles.
Personally I would avoid sequential range like fd00::1, fd00::2
because it exposes you to easy scanning attacks. Random seems
best except for servers.

Regards
   Brian Carpenter

On 02/02/2014 09:18, Henri Wahl wrote:
 Hi,
 
 1) What's the pattern with which addresses are generated/assigned? Are
 they sequential (fc00::1, fc00::2, etc.)?  Random? Something else?

 We use our dhcpy6d (http://dhcpy6d.ifw-dresden.de) which allows 4
 different address categories:
 - sequential range like fd00::1, fd00::2
 - completely random /64 like with privacy extensions:
 fd00::3d2a:563f:76f1:d94f
 - plain MAC address like fd00::2034:d4f1:439a
 - some arbitrary id number given in client configuration like fd00::1,
 fd00::3421
 
 See http://dhcpy6d.ifw-dresden.de/documentation/config/addresses for
 details.
 This way one can hand out for example 2 addresses to clients, one random
 privacy-aware global and one range or MAC-based for internal use. The
 bad news is that only Windows 7+ is capable of handling more than one
 address given by DHCPv6 out of the box. Linux has to be tweaked not to
 use Network-Manager and MacOS fails completely - maybe would work with
 some dhclient or dibbler-client.
 
 2) What about their stability? Is there any intent/mechanism for them to
 be as stable as possible? Or is it usual for hosts to get a new
 address for each lease?
 
 MAC and ID based addresses are of course stable, the range based ones
 intend to be too and the random ones are regenerated whenever a lease
 expired.
 
 Best regards
 Henri