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

[Simon Hobson <[e-mail]>]

Re-ordering the comments slightly ...

Mark Smith <[e-mail]> wrote:

>> Ignoring LL addresses, it seems that only self assigned addresses using deprecated methods (ie based on hardware address) actually *require* a 64 bit split. So on that basis, the standard defining how the protocols work should require implementations to support an arbitrary split.
>> 
> 
> I think the final arbiter in any of these situations is "what is best
> for the end-users?"
> 
> What is the simplest, that will result in lower network capex and opex
> costs to the end-users who directly or indirectly pay those costs?
> 
> What is the most reliable and robust, so that when an end user
> connects to and uses the network, they're least likely to encounter
> issues for which they do not have the technical skillsets to resolve?

The obvious answer to that is "all implementations MUST handle any IID length". That way, when a device does get connected to a network where the IID length isn't 64 bits - it'll still work.
If you leave in any suggestion that an implementation can assume a split 64/64 then some implementations are going to have that embedded in them. If you allow that, and the device gets connected to a network where that isn't the case (for whatever reason*) then it's going to "not work" (either at all or properly).

* We've already seen some suggestions of why that might be - for example where an ISP only provides a single /64 and the user wants more than one network.


>>> This is not recognising that there are more than operational or functional properties of addresses. They have privacy and security properties too.
>> 
>> Shouldn't this requirement be separate from the underlying protocol requirements ?
> 
> No, I don't think so. These protocols fundamentally exist to serve
> end-user needs. If they don't, then they're no more than an academic
> experiment, and we'll have wasted an awful lot of human capital on
> them. These are primary protocol requirements, necessary to meet to
> justify the protocol's existence.

But that's the point I was making - having the IID length at (say) 64 bits is NOT a fundamental requirement. Things would still work just fine even if it was (say) 32 bits, or 16 bits, or ... With shorter lengths (smaller address space) the problem of creating addresses autonomously without clashes becomes harder - but other than that, as long as there is "enough" space then devices will still work.

Where the large address space requirement comes from is a secondary function - privacy. It is not in any way a fundamental limitation in shifting packets about.

> Separate to that (in a separate section), make recommendations (as in "should") to support security and privacy.
>> 
> 
> We've tried that before, making security and privacy optional to
> implement makes it easy to justify not implementing it.

I think there's something of a difference between an optional feature - ie something that needs to be added - and something where it's not a feature that's turned on or off. And the IID length would need to be a lot shorter than 64 bits before the address space becomes trivially smaller. You can't really say the privacy feature is "off" if the IID is only 63 bits, or even down to (say) 32 bits which still gives 4 billion addresses to play with.

If the recommendation is for 64 bits, then it's going to be hard to justify such a small address space that privacy is nullified. And the sort of outfit that does, will be quite happy to do other crap that's harmful to their users - regardless of what any RFC says.

So if you're going to set some arbitrary sizes for IID lengths - then give the real reason which is security/privacy. Because AIUI there is no other fundamental reason to set any restrictions.