Re: [dhcwg] Next step(s) for draft-ietf-dhc-stable-privacy-addresses -> abandon work? / IA_NA applicability

[Lorenzo Colitti <[e-mail]>]

On Wed, Apr 15, 2015 at 3:58 AM, Fernando Gont <[e-mail]>
wrote:

> That is true. In the first version of the I-D we didn't support ranges.
> Now we do, and we should certainly put a huge warning that the address
> space should be huge, or things don't work as expected.
>

Supporting stateless allocation in anything smaller than a /64 is harmful.

You are creating the risk that people coming from outdated IPv4 assumptions
will take a /112, think, "That's big enough for everyone, right? I only
have a few hundred hosts. And I want to limit my subnet size to avoid these
ND cache DoS attacks I've heard about," and get burned by the fact that
there's a 50% chance of collision when there are 250 hosts in the network.
Because your algorithm doesn't support collisions well, they'll be
completely stuck.

Before you argue that it makes sense to support stateless allocation when
the subnet is "large enough" - how large is large enough? People used to
fully-stateful IPv4 deployments with forced forwarding (e.g., large
conference networks that force 1 IPv4 address = 1 MAC address and don't use
broadcast ARP because the wifi chipset filters it out for them) may well do
something like /96 (That's large enough, right? It's the size of the whole
of the IPv4 Internet!) and put 20,000 hosts on it and fall over in the same
way. Yes - large conferences like MWC do have 20k hosts on the same subnet.

Also - if you change the range size, do all the addresses change? That
would make it an even worse idea.