Re: RFC4941bis: consequences of many addresses for the network

[Michael Richardson <[e-mail]>]

Mark Smith <[e-mail]> wrote:
    >> > On Jan 23, 2020, at 8:32 AM, Tim Chown <[e-mail]> wrote:
    >> >
    >> > The problem statement section in 4941bis is all about user privacy, no
    >> mention of operational / management complexity, or other “general problems”
    >> that SLAAC has.  It seems there are unstated problems here :)
    >>
    >>
    >> I would +1 this here.
    >>
    >> I would also generally question if rotating IPs is a adequate privacy
    >> protector considering there are other ways to identify users that are being
    >> (broadly) employed today.
    >>

    > This is the common "it's not perfect, so let's do nothing." Nothing ever
    > improves if perfect is the only threshold of acceptance. (Nothing is ever
    > perfect, there are always trade-offs. If you don't think there are
    > trade-offs, it just means you haven't identified them.)

I also have doubts about whether the rotating temporary address mechanisms
that 4941 provides is useful privacy when the upper-64 bits are unchanging.
But, I agree with you, that it is an improvement... except when it causes
other issues.  So we should consider when and where it's more effort than
it's worth, and when it has benefit.  That requires information that is
presently not available to hosts.

I think that we will need to re-think the ND mechanism(s) and L2/L3 binding
process.  I think that this will cause redesign of hardware switching
fabrics, and I note that it was a good 15 years between IPv4 ARP being
designed and the first hardware switching fabrics, and that was during a time
of much stepper IPv4 deployment than I think IPv6 has had.

I believe that we need to find ways to SEND and SHIM6 (or equivalent)
deployable.

I also think that we need to recognize that we have a number of distinct
deployment environments, and I think that we should be explicit about them:
1) protected home environments
2) guest home environments
3) enteprise environments
4) conference/guest/coffee-shop environments
5)  >4< at ridiculous scale
6) segregated L2 environments with vertically integrated operators (aka
   "LTE", Fred's ATN work, possibly RAW).

I think that the hosts need to know which environment they are in, and need
to change their behaviour.  I think that the DHCP v6only document is the
first of these type of documents.

So I would welcome a document that informed a host system about how many
Temporary is should expect, and we need a to generalize the LLN-specific ND
registration system, so that hosts can get feedback if they use too many,
etc.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-