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

[Mark Smith <[e-mail]>]

On 12 July 2017 at 23:47, Simon Hobson <[e-mail]> wrote:
> Mark Smith <[e-mail]> wrote:
>
>> 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.


> 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?

> 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.

We need to have the Internet secure and private by default. If we make
them options, we should make them options that have to be turned off
rather than on, because that causes the person to make an active and
conscious decision to give them up (whether it is the right decision
for their context is separate, and not one we can control or forecast.
If they're unsure, we are providing the safest default.)

BCP188/RFC7258 is stating that we take this secure and private by
default approach:

"The IETF will strive to produce specifications that mitigate
pervasive monitoring attacks."


Although RFC1726, "Technical Criteria for Choosing IP The Next
Generation (IPng)", doesn't specifically call out privacy, privacy is
a component of security, and it stated that:

"Security should be an integral component of any IPng from the beginning."

It is evident from the Snowden revelations that we dropped the ball on
that (e.g., IPsec was dropped as an implementation requirement per
RFC6434 and became an option), we now need correct that mistake and
take a security and privacy first and by default approach.

Regards,
Mark.