Re: RFC4941bis: consequences of many addresses for the network

[Gyan Mishra <[e-mail]>]

On Fri, Jan 24, 2020 at 12:45 AM Fernando Gont <[e-mail]>
wrote:

> On 23/1/20 20:49, Michael Richardson wrote:
> [....]
> >
> > 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.
>
> As noted by Bob, myself, and others, this is a slaac issue, and not
> something specifically related to 4942bis.
>
> For instance, an ipv6-aware browser might e.g. decide to configure and
> employ different addresses for each tab, or for different apps. And
> you'll end up with way more addresses than those resulting from rfc4941.
>
>
>
>
> >
> > 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).
>
> If you expect hosts to behave nicely with your network, then you should
> probably convey policy information in RAs (as we tried, to some extent,
> in draft-gont-6man-managing-privacy-extensions). At the time, there was
> pushback.
>
> If slaac doesn't convey policy, then nodes do what they assume is in
> their best interest.
>
> And if the network doesn't really like the possible chaos resulting from
> slaac, then it should probably be using dhcpv6.
>
> The nice thing about us doing nothing about the automatic configuration
> mess, is that it typically gets worse: e.g. my CPE sets "M" and "O" in
> RAs, while advertising PIOs for autoconf. So my Ubuntu conf ends up with:
> * slaac stable addresses (RFC7217)
> * slaac temporary addresses (rfc4941)
> * one dhcpv6-leased address
>
>
> PLease let me reiterate: the problem being discussed in this thread is a
> shortcoming of slaac.
>
> It's certainly fine to add a note along the lines of "hey! don't
> regenerate addresses too frequently (i.e., beware when overriding
> default falues(, or else you might end up screwing the network".
>
> But other than that, 4941bis is not about addressing shortcomings of slaac.



Gyan> This draft addresses the operational impacts of multiple addresses
for SLAAC defined with RFC 4862.  With PIO options capability the network
has the ability to send the host multiple addresses to the host.  Some
implementations I have seen have a ULA 4193 address and a GUI address sent
in the SLAAC  PIO prefix list.  Although I have tested this scenario in the
lab, practical  use of the address and which to use with the host OS
default source address selection algorithm is too complicated.  It would be
nice if you could use the ULA for internal intranet communications and GUA
for external but unfortunately it does not work that way.  Their is a
pecking order built with the source address selection algorithm and thus
the same address ends up being used all the time for all flows.  Defeats
the purpose or reason to have multiple addresses if the same one always
gets used.

Most host Operating Systems such as Windows and MAC by default have RFC
4941 privacy extensions implemented which generate a temporary address
which has default valid and preferred lifetime which are configurable by
the operator.

Definitely having multiple addresses on a host from an operations
prospective adds tremendous complexity.

Operations and user operational late of complexity is added to now
determine which address is used for conversation flows.

By default most operating systems both windows Mac and others follow a
default address selection pecking order to determine which address.  RFC
6724 defines this default address selection algorithm used in cases where
multiple PIO addresses exist on the host.  End result of the source address
selection algorithm is the same address is used all the time.

With implementations I have deployed personally from an operators and IT
security perspective as a standard for host images we would disable the
privacy extension temporary 4941 privacy address and also disable the
random IID so end hosts IPv6 address is stable.  For IT operators
simplicity is key for troubleshooting and trying to determine which address
is used for a conversation flow is an operations nightmare.  IPv6 SLAAC
address privacy makes sense and is Ok if you are connected to the internet,
however on corporate owned host endpoints for endpoint security “stable”
address is utmost importance.

My recommended direction for operator is to disable SLAAC random IID and
temp privacy address until RFC 7217 semantically opaque IID and RFC 8064
stable IID are implemented by host OS vendors which as Microsoft and
Apple.  Also for simplicity in troubleshooting from operations perspective,
even though IPv6 with PIO options had the ability to send unlimited number
of prefixes to a host I would recommend only sending a single address.

Since this draft talks about all the IID generation schemes I think it
should talk about operational impact of each option implemented.  Maybe
there should be another draft which discusses SLAAC IID options and
operational impact

I can kick start a draft that discussed this topic and makes a
recommendation as I mentioned above.

Kind regards

Gyan



>
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
-- 

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]