Re: IPv6 Routing & ND vs. Addressing, (Was: Re: <draft-ietf-6man-rfc4291bis-09.txt>)

On 12/07/2017 11:54, Mark Smith wrote:
>> On 12 Jul. 2017 03:21, "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
>> wrote:
>> 
>> From: David Farmer [mailto:farmer@umn.edu]
>> 
>>> IPv6 as currently defined does actually require IIDs to be 64 bits,
>>> if this wasn't the case then you could use subnets of any length
>>> without any special requirements or considerations.
>> 
>> And in general, you can. I think this is a stumbling block. There are
>> examples where 64-bit IIDs are still required, and there are examples where
>> they were required for reasons that no longer apply. But as of now, if you
>> use static addresses, or similarly DHCPv6, you're not limited. Everything
>> works fine with shorter IIDs.
>>
> 
> This is not recognising that there are more than operational or functional
> properties of addresses. They have privacy and security properties too.

Very specifically, it would be irresponsible not to require pseudo-random
IIDs of at least N bits for automatically assigned addresses. RFC7217
doesn't define N, but I assume it would be at least 40 and probably more.

The advantage of requiring or recommending 64 bits is that it avoids the
debate about N. I prefer 'recommend' because it avoids enumerating all
possible exceptions. We've seen how hard it is to wordsmith the exceptions.

     Brian

> As an example, the stateful DHCPv6 server in OpenWRT currently compromises
> those security and privacy properties as it is enabled by default, as the
> range of IIDs it uses is the same size as the DHCPv4 server's address range
> e.g. 100 addresses. (OpenWRT supports both SLAAC and Stateful DHCPv6 by
> default, my hosts that support both had great private/secure addresses
> through SLAAC and terrible ones through DHCPv6)
> 
> In IPv4, this is less of a concern, because NAT provided a layer of
> security and privacy to individual hosts' addresses, in particular to
> residential users. If we advocate for removing NAT from IPv6, or more
> accurately advocate end-to-end addressing, we need to provide alternate
> methods to restore the privacy and security provided by NAT.
> 
> Those methods should also not be reliant on devices or functions in the
> network, because the hosts that need them the most are also very portable
> (i.e., smartphones and laptops), and are easily and commonly attached to
> untrustable public networks.
> 
> 
> If
> 
> you use SLAAC, you are limited to 64-bit IIDs, but that limitation is
> self-imposed, to try to keep other-than-64-bit-IIDs from becoming too easy
> to configure. In principle, it would be easy enough to remove that 64-bit
> limitation from SLAAC.
> 
> I'm opposed to continue to imply that 64-bit IIDs are "required," other
> than in cases like SLAAC, ULAs, LLAs. That word "required" is what causes
> the pushback.
> 
> Bert
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 