Re: RFC4941bis: consequences of many addresses for the network

[Gyan Mishra <[e-mail]>]

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

> On 24/1/20 11:54, Gyan Mishra wrote:
> >
> > Operators already have the option of not using the default valid and
> > preferred lifetimes.  Most operators don’t change the default values so
> > maybe  a suggestion could be to change the default values of of the
> > temporary address regeneration would help with stability.
>
> NOt sure what you mean.
>


The router in the RA can can set the valid and preferred lifetime if
desired on each subnet for the SLAAC prefix received.  I believe when
that’s done the temporary address inherits the same values.

>
>
> > Also disable temporary address regeneration churn is an issue to make
> > the address stable by disabling the privacy extension.  If security and
> > tracking of IPv6 addresses in use is a concern, disable the random
> > station ID defaulting to the modified EUI64 format.
>
> NO idea what this means. You shouldn't use EUI64-nbased addressess. If
> you need stable addresses, that's what RFC7217 is for.
>

When you disable the random station ID the default is Modified EUI64 not
EUI64 for Microsoft and Apple devices.  I agree RFC 7217 stable address is
most preferred however Microsoft and Apple don’t support yet.

>
>
>
> > Can we mention in the draft that a stable IID with privacy extension and
> > not having a separate temporary address is the directional approach for
> > 6MAN to RFC 7217 and 8064.  Does everyone agree???
>
> That's a misrepresentation of RFC7217 and RFC8064.
>
> RFC7217 specifies an alternative algorithm (to EUI64-baed) for
> generating stable addresses. RFC8064 simply recommends RFC7217 over the
> traditional slaac addresses that embed a mac address.


I believe we are saying the same thing.

>
   I am not trying to mix apples with oranges although it sounds that way
since RFC 7217 does not use temporary address but achieve the same privacy
goals with the alternative algorithm.

>
Do you agree that RFC 7217 algorithm to generate a stable IID is the best
approach out of all the slaac IID generation options that exist today,


>
> Those two documents don't say much about temporary addresses -- and they
> shouldn't, since they are about stable addresses.
>
> Agreed.  Understood.  My point is to recommend RFC 7217 stable address as
> currently the best option available.  Also obsolete or deprecate RFC 4941.


>
> > Also mention caveats with having multiple addresses from an operations
> > perspective is not desirable per the default source address selection
> > algorithm RFC 6724.  With RFC 6724 and predecessor 3484you are not
> > gaining anything with multiple addresses as the same address is always
> > used.  So the recommendation is to not send multiple slaac prefixes.
>
> Not sure what you mean. RFC6724 is, in fact, all about leveraging
> multiple addresses.
>

Yes it is but it does not do I believe what the author envisioned it to
do.  I believe that is to be able to use one slaac source address selected
for certain flows such as intranet internal flows and be able to
simultaneously use another address for different flows.  That is not
possible.  That goes to the point that IPV6 allows for many prefixes to be
sent to the slaac host, however the host does not have any means of using
more then one at a time unfortunately.

>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: [phone]

Email: [e-mail]