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

[Brian E Carpenter <[e-mail]>]

On 12/07/2017 15:18, Manfredi, Albert E wrote:
> -----Original Message-----
> From: Brian E Carpenter [mailto:[e-mail]] 
> 
>> 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.
> 
> Exactly. This is one example that should not mandate 64, but rather whatever is enough for all the considerations that have to be made. For collisions or security, 48 or 40 bits is probably plenty, depending also on the number of hosts expected in a subnet prefix. Within a homenet, I'd much rather depend on a firewall than an overabundance of IID bits, for instance.
> 
>> The advantage of requiring or recommending 64 bits is that it
>> avoids the debate about N.
> 
> But it penalizes applications that would benefit from more flexibility. Much of the problem comes from our inability to even define what a "site" might be, to which a /48 might theoretically be assigned (if we even believe that's a realistic expectation anymore?). So, not knowing what constitutes "site," and not believing that all sites will get anything better than a /64, I think we need to avoid having device makers create hard 64-bit IID boundaries. It would be unfortunate if every thermometer and thermostat were required to have a 64-bit IID. *Or* were built that way, because someone read that 64-bit IIDs are "required."

I'm not convinced. I'm arguing for flexibility so that we don't look
stupid in 50 years time, but 15 trillion /48s is an awful lot of /48s,
even for the Internet of Things. I don't really have a problem with
64 bit IIDs in light switches.

    Brian