Subject: Re: Prefix randomization

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 1 Jun 2018 09:22:24 +0200

Le 31/05/2018 à 10:39, Fernando Gont a écrit :
[...]
>> If a per device prefix is used and is
>> persistent, the device (and hence user) are trackable in the Internet
>> regardless of what is done in the IID space. RFC4941 only mentions
>> this problem in passing, it doesn't attempt to address it.
> 
> The host can't do it. Since you don't control the prefix that is giving
> to you, of course you are at the mercy of your ISP to "track you" based
> on the prefix.

Well.  It _is_ possible to control the prefix to a certain extent.

In a single-subnet LAN two parties could use the prefixes they decide (a 
ULA), to avoid being tracked by a third party in that LAN.

Up above, it is possible that host injects a route for its host-decided 
prefix to those routers who accept it.  This happens without machine 
control (with human control) at very top levels in the Internet.

With respect to ISPs: some ISP may accept that two smartphones or two 
CPEs do use some prefix they decide among themselves for peer-to-peer 
communication, instead of the prefix ISP allocates to each.

In Enterprise setting it is the case too.

It is a good perspective to keep: prefix randomization.

Alex

> 
> 
>> I've written an I-D on this
>> (https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00).
>> That might provide some input for RFC4941-bis for this issue.
> 
> I will provide a review now. Apologies for not doing it before, since I
> had promised I'd do it.
> 
> Thanks!
> 
> Cheers,
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 4 Jun 2018 15:48:12 +0300

> Well.  It _is_ possible to control the prefix to a certain extent.

You don't control global prefixes. And those are the ones that, for the
most part, matter.

> ULA), to avoid being tracked by a third party in that LAN.
If you don't need a "public" network, and nevertheless have to "agree"
on which prefix you are going to use, then:

1) Don't use a public network and set up an ad-hoc network instead, and,

2) If you only need to communicate on the local-link, use link-local
addresses -- you don't need ULAs for that.

> control (with human control) at very top levels in the Internet.

Could you please describe the scenario you're referring to?

> communication, instead of the prefix ISP allocates to each.

Are you expecting to be able to somehow inject ULA prefixes into the ISP
or what? -- Sounds extremely unrealistic to me.

> It is a good perspective to keep: prefix randomization.

The first thing you need to think about is that an address is an address
because it depends on the network topology/graph. When you connect to a
network, you become part of such graph, and part of your address is
determined by it.

he part of the address that you get to play with is the part that is not
topologically-dependent, and that, in general, the network does not care
about as long as the resulting address is unique.

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

---

From: Johanna Ullrich <[email-masked]>
Date: Tue, 5 Jun 2018 12:44:28 +0000

Dear Fernando,

I carefully reviewed your draft, especially the algorithms for interface identifier generation, and as you know strongly support revision of RFC4941.

>From a security perspective, the "simple randomized interface identifiers" of section 3.2.1 are stronger than their hash-based alternative of section 3.2.2 for the following reason:
The address algorithm (hopefully) uses the random number generator of the operating system; in case the later is compromised, the chance that this generator is quickly replaced by a secure alternative is high as a good generator is necessary for manifold operations, in particular cryptography. With this line of action an update of the Privacy Extension comes automatically.

The hash-based generation of randomized interface identifiers per se is not insecure. But there is the chance that out-dated hash algorithms are used at the time of implementation or that the used hash algorithms become out-dated in the future. Regaining a secure implementation then implies changing the Privacy Extension's implementation.

In addition, there is no randomness in the calculation of the randomized interface identifiers. The correlation by a third party is prevented by the fact that the secret key is unknown to this third party (and is based on plain cryptography). Following the principle of Kerkhoff, a way to change the key/generate a new key has to be provided in case the user knows or believes that the key has been leaked. Otherwise, an adversary that has gained the key is able to predict future interface identifiers with modest effort (in particular dependent on TIME's granularity). I see relying on a secret key also as an issue with regard to pervasive monitoring, e.g., by state authorities, as described in RFC758.

For these reasons, I would prefer the first alternative as long as there is no other rational in offering two alternatives beyond the fact that the hash-based generation is similar to RFC7217. 

Beyond, I would add a section enumerating the events that require regeneration of a new interface identifier, e.g., change of MAC address, movement to another network, etc. as this was not clearly stated in the RFC. 

Finally, item 4 in the enumeration of section 3 (at the begin) states that there is one address for each advertised prefix. I would further specify that these addresses contain different interface identifiers; otherwise, an adversary could perform correlation among these addresses.

Feel free to contact me for further reviews or contributions to this draft!
I am willing to contribute.

Cheers,
Johanna

Dr. Johanna Ullrich
Senior Researcher
http://www.sba-research.org/

Identifizierung gemäß § 14 UGB
 Firmenname: SBA Research gGmbH
 Firmensitz: Favoritenstraße 16, 1040 Wien
 Firmenbuchnummer: 345659y
 Firmenbuchgericht: Handelsgericht Wien
 DVR-Nummer: 4012257

________________________________________
Von: ipv6 <[email-masked]> im Auftrag von Bob Hinden <[email-masked]>
Gesendet: Donnerstag, 31. Mai 2018 20:22
An: Fernando Gont
Cc: IPv6 List; Bob Hinden; 6man Chairs
Betreff: Re: Adoption call for <draft-fgont-6man-rfc4941bis-01>

Fernando,

> On May 31, 2018, at 1:19 AM, Fernando Gont <[email-masked]> wrote:
>
> Hi, Bob,
>
> On 05/30/2018 11:19 PM, Bob Hinden wrote:
>> I wanted to note that we also asked:
>>
>> "Could those who are willing to work on this document,
>> either as contributors, authors or reviewers please notify the list.
>> That gives us an indication of the energy level in the working group
>> to work on this."
>>
>> We haven’t seen anyone respond to this yet.
>
> Just curious: isn't the support of wg adoption somehow an implicit
> agreement that folks are willing to work on the document by e.g.
> reviewing it?

I theory yes, but in practice, not so much  :-(

Bob

---

From: Fernando Gont <[email-masked]>
Date: Thu, 14 Jun 2018 18:59:50 +0300

Hello, Johanna,

Thanks so much for your careful review and your commitment to this
effort! -- PLease find my comments in-line....

On 06/05/2018 03:44 PM, Johanna Ullrich wrote:
> 
> I carefully reviewed your draft, especially the algorithms for
> interface identifier generation, and as you know strongly support
> revision of RFC4941.

Thanks!

>> From a security perspective, the "simple randomized interface
>> identifiers" of section 3.2.1 are stronger than their hash-based
>> alternative of section 3.2.2 for the following reason:
> The address algorithm (hopefully) uses the random number generator of
> the operating system; in case the later is compromised, the chance
> that this generator is quickly replaced by a secure alternative is
> high as a good generator is necessary for manifold operations, in
> particular cryptography. With this line of action an update of the
> Privacy Extension comes automatically.
> 
> The hash-based generation of randomized interface identifiers per se
> is not insecure. But there is the chance that out-dated hash
> algorithms are used at the time of implementation or that the used
> hash algorithms become out-dated in the future.
>
> Regaining a secure
> implementation then implies changing the Privacy Extension's
> implementation.

Note that the use of hashes we're doing here is different than that for
e.g. cryptographical signatures.

> In addition, there is no randomness in the calculation of the
> randomized interface identifiers. The correlation by a third party is
> prevented by the fact that the secret key is unknown to this third
> party (and is based on plain cryptography) > Following the principle
> of Kerkhoff, a way to change the key/generate a new key has to be
> provided in case the user knows or believes that the key has been
> leaked. Otherwise, an adversary that has gained the key is able to
> predict future interface identifiers with modest effort (in
> particular dependent on TIME's granularity). I see relying on a
> secret key also as an issue with regard to pervasive monitoring,
> e.g., by state authorities, as described in RFC758.
> 
> For these reasons, I would prefer the first alternative as long as
> there is no other rational in offering two alternatives beyond the
> fact that the hash-based generation is similar to RFC7217.

The reasoning for "specifying" the algorithm similar to RFC7217
essentially are:
1) Implementations might want to reuse the code
2) The change of MAC address resulting in a change of IPv6 address
happens automagically in the algorithm.

(mostly "1)" rather than "2)", I'd say).

Question: Do you suggest that we explicitly recommend the algorithm
based on random() rather than the one based on RFC7217?  Or do you
suggest that we should remove the algorithm based on RFC7217 altogether?

> Beyond, I would add a section enumerating the events that require
> regeneration of a new interface identifier, e.g., change of MAC
> address, movement to another network, etc. as this was not clearly
> stated in the RFC.

This is correct. The question here is whether that should be in this
document, or on a document about requirements for temporary addresses
(such as draft-gont-6man-non-stable-iids, (ala RFC8064)).

Thoughts?

> Finally, item 4 in the enumeration of section 3 (at the begin) states
> that there is one address for each advertised prefix. I would further
> specify that these addresses contain different interface identifiers;
> otherwise, an adversary could perform correlation among these
> addresses.

Yes, this issue is the same as the previous one: whether to put all
stuff on this document, or keep the requirements and the specific
implementation details in separate documents.

Thoughts?

Thanks so much!

Best regards,

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jun 2018 22:44:46 +0200

sorry for late reply.

Le 04/06/2018 à 14:48, Fernando Gont a écrit :
> You don't control global prefixes.

Well, indeed I dont.  But some people do.

  And those are the ones that, for the
> addresses -- you don't need ULAs for that.

In principle yes, but it is not all.

You could have two cars that talk to each other through the cellular 
network.  They make sure they exchange their ULA prefixes through the 
cellular network, maybe over some tunnel interface.  Each one will still 
need the cellular network to connect to the Internet.

They can't set an 'ad-hoc' network just between them if all they have is 
cellular interfaces (no WiFi).

They cant use link-local addresses because the ptp links used in 
cellular networks are representing each a single IP subnet.  So any LL 
addressed packets wont go to the other ptp link.

> Could you please describe the scenario you're referring to?

This is something about the DFZ: Default Free Zone.

But it is maybe too high level to speculate on it.  It's something 
dangerous to touch.

I meant that up there those people doing BGP can put whatever they want 
into the routes.  And if they want some privacy, then they can put some 
random prefixes.

Just a little bit at a little below layer, there are places where there 
was some experimentation with BGP route injection between planes and 
some ground stations.  There too, they could have put randomized prefixes.

> or what? -- Sounds extremely unrealistic to me.

Some ISP may accept route injection.

But it's not absolutely necessary to accept.

> network, you become part of such graph, and part of your address is

I agree with you.  It is called an address in order to address something 
in a topology which cant exist without addresses.  Yet there are exceptions.

I think in the Internet it is very well possible for two parties to 
generate their private randomized prefixes and communicate privately. 
There are a few conditions for that to work.

(but I also think that there are so many security problems in the 
Internet that maybe this prefix randomization is not the most urgent to 
think about.  For example, one very urgent security matter for me is the 
essence itself of the Certificate Authorities, and the lack of trust 
between many organisations, including lack of trust in ciphering, or 
lack of trust in export control rules, and so on.  If I am to follow 
strict rules to which I otherwise abide a lot, then I should stop even 
posting to IETF email lists :-)

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 16 Jun 2018 11:03:45 +1200

>> You don't control global prefixes.

It's unclear to me whether this means "globally routeable" prefixes
or "global scope" prefixes. The latter includes ULAs, the former
does not.

> cellular interfaces (no WiFi).

In that case, the ULA prefixes are irrelevant, because they are not
globally routed.
 
> addressed packets wont go to the other ptp link.

Correct, and they can't use ULAs either unless some kind person
sets up local routing between them. Can you explain how that
might happen?
 
> This is something about the DFZ: Default Free Zone.

That is well known to be an illusion. Even if it was real, it
definitively does not route ULA prefixes.
 
> into the routes.  And if they want some privacy, then they can put some 

I hope you're not suggesting that BGP would be used between various cars
waiting at the same traffic light. What routing protocol do you think
they would use?

    Brian
 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 16 Jun 2018 12:04:36 +0200

Le 16/06/2018 à 01:03, Brian E Carpenter a écrit :
> That is well known to be an illusion.

Do you mean each other computer on the Internet has a default route?

> Even if it was real, it

Ok, but it is very well possible to put a randomized prefix in the DFZ 
(not an ULA), agreed between two persons.

> waiting at the same traffic light. What routing protocol do you think

Well, the way choices are made which protocol depend very much on their 
price money cost.  It is possible that BGP has some open source cheap 
implementation, that is easy for a programmer to deploy on a particular 
car.  And other protocols known as less heavy, or 'lighter' to not be 
selected, because they are expensive in terms of money, expensive 
programmer skill, lack of availability on a particular embedded 
platform, lack of publicly reported interoperability, and other criteria.

For the protocol on the traffic light it is more complicated because 
requires involvement from important organisations, there are some risks.

And yes, I do see routing protocol like BGP on the car and on the 
traffic light controller and on the traffic light enforcer ('speedcam' 
in English, 'radar' in French), provided the implementation is cheap and 
the programmer feels at ease with it.

I think that if people use this BGP in the DFZ it means they thought a 
lot about securing it, about how to trust each other; whereas the people 
who design e.g. RPL for LLN typically happens on a single table, where 
that programmer is the only omnipotency, so the trust is easily assumed 
to be a given.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 17 Jun 2018 12:14:30 +1200

In line...

> Do you mean each other computer on the Internet has a default route?

No. I mean that there is no such thing as a single subset of BGP4 routers
that all contain the same set of prefixes and no default routes. It's not
certain that such a subset ever existed, and it's certain that it doesn't
exist today. By the same token "globally routed" is fairly meaningless,
as was discussed when ULAs were first defined:
https://mailarchive.ietf.org/arch/msg/ipv6/h59DTVcr0WKN7JiAK5KpZ8YnILw
("globally routeable" is meaningful, however, but excludes ULAs.)
 
> (not an ULA), agreed between two persons.

If there was a DFZ, yes. But I think you mean: in the routing tables
for that part of the topology that happens to include the vehicles
and fixed equipment concerned. So if a German tourist and a French tourist
are at the same traffic light in Skopje, you need to inject that route
in which routers?
 
> the programmer feels at ease with it.

That discussion doesn't belong here, but it seems to me that this is
vastly outside the BGP4 design space.

> lot about securing it, about how to trust each other; 

I hear the Internet backbone operators rolling on the floor and laughing.

> whereas the people 

Sure. This is a hard problem, to be solved in the routing area IMHO.

    Brian

---

From: Johanna Ullrich <[email-masked]>
Date: Mon, 18 Jun 2018 13:31:21 +0000

Hello Fernando,

>> e.g. cryptographical signatures.

I know but this has also been the case for the "old" MD5-based Privacy Extension.
The MD5 algorithm has been fast in calculation allowing an adversary to easily pre-calculate future addresses of the victim,
and all kind of cryptographic attacks make this calculation easier for the adversary.

>> suggest that we should remove the algorithm based on RFC7217 altogether?

My preferred alternative is removal of the RFC7217-based algorithm.
An explicit recommendation of the random identifiers while leaving the RFC7217-based there is the second-best alternative ;-)
In this case, I would provide pros and cons of the alternatives.
In no way, I would leave them as in the current draft and leave the decision to the one who is implementing without guidance.

>> implementation details in separate documents.

In such a case, I would go for a separate document as the individual address formats can be changed/updated independently from this document.

Cheers,
Johanna

Dr. Johanna Ullrich
Senior Researcher

________________________________________
Von: Fernando Gont <[email-masked]>
Gesendet: Donnerstag, 14. Juni 2018 17:59
An: Johanna Ullrich
Cc: IPv6 List; 6man Chairs
Betreff: AW: Adoption call for <draft-fgont-6man-rfc4941bis-01>

Hello, Johanna,

Thanks!

Thoughts?

Thoughts?

Thanks so much!

Best regards,

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 18 Jun 2018 23:29:39 +0900

On Tue, Jun 5, 2018 at 9:44 PM Johanna Ullrich <[email-masked]>
wrote:

> In addition, there is no randomness in the calculation of the randomized
> interface identifiers. The correlation by a third party is prevented by the
> fact that the secret key is unknown to this third party (and is based on
> plain cryptography). Following the principle of Kerkhoff, a way to change
> the key/generate a new key has to be provided in case the user knows or
> believes that the key has been leaked. Otherwise, an adversary that has
> gained the key is able to predict future interface identifiers with modest
> effort (in particular dependent on TIME's granularity). I see relying on a
> secret key also as an issue with regard to pervasive monitoring, e.g., by
> state authorities, as described in RFC758.
>

+1. The algorithm as specified allows an attacker who somehow obtains
knowledge of the key (for example, via a security vulnerability that is
later fixed) to predict all the addresses that will be generated until the
end of time. This is highly undesirable for addresses that are expected to
provide privacy. I don't think we should recommend this algorithm without
some additional randomness mixed in.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 18 Jun 2018 23:43:19 +0900

On Wed, May 30, 2018 at 4:20 PM Ole Troan <[email-masked]> wrote:

>     Title     : Privacy Extensions for Stateless Address Autoconfiguration
> in IPv6
>     Authors   : F. Gont, S Krishnan, T. Narten, R. Draves
>     Filename  : draft-fgont-6man-rfc4941bis-01
>     Pages     : 19
>     Date      : 2018-03-25
>

I think this text:

          We note that [RFC4291] requires that the Interface IDs of all
          unicast addresses (except those that start with the binary
          value 000) be 64 bits long.  However, the method discussed in
          this document could be employed for generating Interface IDs
          of any arbitrary length, albeit at the expense of reduced
          entropy (when employing Interface IDs smaller than 64 bits).

should be removed, for two reasons:

1. It's confusing because it mentions something that is in direct conflict
with a standards track RFC.
2. It's unhelpful because while it vaguely mentions "reduced entropy", it
neither mentions the problems that can be caused by reduced entropy
(increased collisions, and, when DAD fails, duplicate addresses which
result in totally broken connectivity), nor provides any way to gauge how
likely those effects are.
3. It doesn't even say that the random number must be at least 64 bits long.

If you want to mention that unicast addresses starting with binary 000 can
use different prefix lengths, then say that. Such a statement is useless in
practice, because no network exists (and currently, no network can exist)
that uses these ranges, but at least it's not confusing.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 Jun 2018 08:49:45 +1200

> should be removed, for two reasons:

I think it should be retained, because it's true.
 
> with a standards track RFC.

Why is that confusing? It isn't written as normative text; it isn't even
phrased as implementation guidance.

> likely those effects are.

Clearly, any normative text about using different lengths would
need to discuss that. But this isn't normative text.

> 3. It doesn't even say that the random number must be at least 64 bits long.

Since it's talking about an arbitrary length, why would it say that?

We did actually discuss this topic a little in
https://tools.ietf.org/html/rfc7421#section-4.5

    Brian

---

From: David Farmer <[email-masked]>
Date: Mon, 18 Jun 2018 17:16:41 -0500

> phrased as implementation guidance.

It is not in conflict with the totality RFC4291. Yes, Section 2.5.1 says
"For all unicast addresses, except those that start with the binary value
000, Interface IDs are required to be 64 bits long" However, Section 2.5
says "A slightly sophisticated host (but still rather simple) may
additionally be aware of subnet prefix(es) for the link(s) it is attached
to, where different addresses may have different values for n:"  In its
totality, it seems quite clear to me that RFC4291 envisions the possibility
that a 64-bit IID is not necessarly true for all addresses forever and
ever. It clearly contemplates addresses with other IID lengths, at least
those starting with the binary value 000, but it also seems to contemplate
the possibility of changing the 64-bit value more generally. Furthermore,
most of the rest of the IPv6 specifications seem to envision the
possibility that Section 2.5.1 could be changed as well. Otherwise, they
would treat the 64-bit IID as a constant for addresses not starting with
the binary value 000, which they do not seem to do.

All the statement you object to says is the algorithm discussed is not
dependent on a 64-bit IID length, which seems true to me, and is consistent
much of the rest of the IPv6 specifications, especially with RFC4861,
RFC4862, and the totality of RFC4291. If there is any contradiction it's
inherent in RFC 4291 and built into much, if not all, of IPv6.

> need to discuss that. But this isn't normative text.

+1

> Since it's talking about an arbitrary length, why would it say that?

+1

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Jun 2018 08:44:05 +1000

On Tue, 19 Jun 2018 at 08:17, David Farmer <[email-masked]> wrote:

> [email-masked] <[email-masked]>> wrote:
>

If it is going to stay, it needs to be changed to

"However, the method discussed in this document could be employed for
generating Interface IDs of any arbitrary length, albeit at the expense of
reduced or possibly significantly reduced privacy (when employing Interface
IDs smaller than 64 bits)."

"Entropy" is an abstract term that isn't capturing the privacy impact. That
impact is particularly important to capture in document that has a title
starting with "Privacy Extensions ..."

Some people reading document (or who have English as a second language) in
the future may not know or remember the meaning of the word "entropy" (it
isn't a very commonly used word), and therefore not realise what the above
statement is saying.

> possibility that Section 2.5..1 could be changed as well. Otherwise, they

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jun 2018 08:20:02 +0300

> An explicit recommendation of the random identifiers while leaving the RFC7217-based there is the second-best alternative ;-)

Ok. I'm okay either way. Let me start a separate thread for folks to
voice their opinion on this particular topic, and we go with whatever
option is agreed upon.

> In no way, I would leave them as in the current draft and leave the decision to the one who is implementing without guidance.

Agreed.

> In such a case, I would go for a separate document as the individual address formats can be changed/updated independently from this document.

That was my take as well. Will ask for feedback about this, too, so that
folks can voice their opinion.

Thanks!

Best regards,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 Jun 2018 08:13:43 +0300

Hello, Lorenzo,

On 06/18/2018 05:43 PM, Lorenzo Colitti wrote:
> On Wed, May 30, 2018 at 4:20 PM Ole Troan <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>         Title     : Privacy Extensions for Stateless Address
>     Autoconfiguration in IPv6
> 1. It's confusing because it mentions something that is in direct
> conflict with a standards track RFC.
> 2. It's unhelpful because while it vaguely mentions "reduced entropy",
> it neither mentions the problems that can be caused by reduced entropy
> result in totally broken connectivity), nor provides any way to gauge
> how likely those effects are.

FWIW, I don't mind removing this text. It is there because the text is
based on RFC7217, which contains this text. But I don't mind removing it.

> 3. It doesn't even say that the random number must be at least 64 bits long.

To the extent that is feasible, I'd word it as "of an appropriate
length" or the like. But wouldn't mind saying "of at least 64 bits long".

> If you want to mention that unicast addresses starting with binary 000
> can use different prefix lengths, then say that. Such a statement is
> useless in practice, because no network exists (and currently, no
> network can exist) that uses these ranges, but at least it's not confusing.

No. I wouldn't like any sort of discussion related to IID lengths here
(at the end of the day, such discussion would also apply to RFC7217, too).

The only intent was not to hardcode any values in this spec, simply
because it's not needed, and doesn't belong here.

Thanks!

Cheers,

---

From: Bob Hinden <[email-masked]>
Date: Fri, 22 Jun 2018 09:14:21 -0700

Hi,

The chairs think there is support to adopt this draft as a 6man document.

We note a few things that we would like to see done.  These are:

<draft-fgont-6man-rfc4941bis-00> established a baseline from RFC4941. <draft-fgont-6man-rfc4941bis-01> has a large number of changes.  The diff can be found at:

https://tools.ietf.org/rfcdiff?url2=draft-fgont-6man-rfc4941bis-01.txt

These changes are summarized in Section 8 of the draft as:

   1.  Discussion of IEEE-based IIDs has been removed, since the current
       recommendation ([RFC8064]) is to employ [RFC7217]).
   2.  The document employs the terminology from [RFC7721].
   3.  Sections 2.2 and 2.3 of [RFC4941] have been removed since the
       topic has been discussed in more detail in e.g.  [RFC7721].
   4.  The algorithm to generate randomized interface identifiers was
       replaced by two possible alternative algorithms.
   5.  Generation of stable addresses is not implied or required by this
       document.
   6.  Temporary addresses are *not* disabled by default.
   7.  Section 3.2.1 and 3.2.2 from [RFC4941] were replaced with
       alternative algorithms.
   8.  Section 3.2.3 from [RFC4941] was removed, since such alternative
       approaches.
   9.  All the verified errata for [RFC4941] has been incorporated.

We would like to find volunteers to review all of the changes and see if they are appropriate.  Also, to review any other changes not listed.  Please contact the chairs.

The -01 draft removes acknowledgments that are in RFC4941, we think these should be restored.  It is a bis document.

The -01 draft has references to a several individual Internet Drafts, we are not sure these should be listed in a revision to RFC4941.  We would like to see this discussed.

Thanks,
Bob & Ole

> On May 30, 2018, at 12:20 AM, Ole Troan <[email-masked]> wrote:
> 
> This message starts a two week 6MAN call on adopting:
> 
>     Title     : Privacy Extensions for Stateless Address Autoconfiguration in IPv6
>     https://datatracker.ietf.org/doc/draft-fgont-6man-rfc4941bis/
> 
> as a working group item. Substantive comments and statements of support
> for adopting this document should be directed to the mailing
> list. Editorial suggestions can be sent to the authors.  This adoption
> call will end on June 12th, 2018.
> 
> Could those who are willing to work on this document,
> to work on this.
> Regards,
> Bob and Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Jun 2018 19:39:13 +0200

Hello, Bob,

> The chairs think there is support to adopt this draft as a 6man document.

Should we resubmit as draft-ietf?

> The -01 draft removes acknowledgments that are in RFC4941, we think these should be restored.  It is a bis document.

Indeed. If you have a suggestion on how to do that ("this document is a
revision of... the authors of that document wanted to thank..."?),
please do let me know (I didn't know how to proceed here).

> The -01 draft has references to a several individual Internet Drafts, we are not sure these should be listed in a revision to RFC4941.  We would like to see this discussed.

Indeed, part of the discussion is whether we should have a document with
the requirements (a la RFC8064), an have RFC4941 focus on an
implementation that complies with such requirements, whether to
incorporate the requirements here, or what. I'd probably go for the
former, since it mimics what we did for stable addresses (requirements
in one document, implementation details in another).

Should I start a new thread to discuss this?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Bob Hinden <[email-masked]>
Date: Fri, 29 Jun 2018 15:48:08 -0700

Fernando,

> On Jun 29, 2018, at 10:39 AM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Bob,
> 

Yes, once there is some change in content.

> please do let me know (I didn't know how to proceed here).

Something like having it in two parts, the first original acknowledgments for RFC4941, and the second for the bis document.

> Should I start a new thread to discuss this?

Yes.

Thanks,
Bob