Subject: Chairs review: draft-ietf-6man-stable-privacy-addresses-01

From: Ole Troan <[email-masked]>
Date: Thu, 20 Dec 2012 15:40:37 +0100

all,

the ADs have asked us to ensure that there are good review of documents in the
working group, prior to them being advanced to the IESG.
as a part of document last calls in the 6man working group, Bob and I want to try
using volunteers and/or w.g. chair reviewers, that take specific responsibility to
review documents in WG last call.
Bob and I have reviewed this document.

General comments:
--------------------------
We do see the usefulness of a interface-id generation algorithm, that results
in stable identifiers per IPv6 prefix, while not being derived from link-layer
MAC addresses.

The mechanism proposed could be viewed as an modification of temporary addresses (RFC4941)
with lifetime handling as for SLAAC, or as an extension to CGA (RFC3972) address
generation where the public key is removed from the hash. 

The method for generating "Stable privacy addresses" needs to be as well specified
as temporary addresses (RFC4941).
We do wonder if the method of generating these addresses could be a modification of the
algorithm in RFC4941, or if at least, larger parts of the text in RFC4941 could be 
references avoiding having to duplicate lots of text into this document.

We do not believe the current revision of the document is ready to advance to the IESG.

Major points:
-----------------
- Stable Privacy Enhanced Addresses (SPE Addresses) should not be a replacement for the
  algorithm specified in RFC2464. It is an alternative. Section 3 needs modification.

- The algorithm in the document  is underspecified.
  o It should specify the hash function. E.g. MD5 as RFC4941.
  o It should handle reserved interface-ids (see 4941).
  o We suggest renaming the “secret key” to “modifier”. And add text describing
    how to ‘maintain’ the modifier (section 3 of RFC3972).
  o It would be useful to include an example algorithm as has been done in some other documents.
  o Not all implementations use interface indexes

- Clarify what lifetimes these addresses have.

- Specify the default for DAD retries (IDGEN_RETRIES)

- Clarify the requirements for stable storage (compared to RFC2464)

Minor points:
-----------------
Don't use the term "static addresses" as that implies static aka manual configuration.
These addresses are not static in that sense.

Section 3, Last Paragraph:
The reference to Node Information Queries only applies if the attacker is onlink.
Current text overstates the problem. Move to security considerations. Addresses will
leak regardless, in other communication, email header etc.

6. Security Considerations.
s/in replacement of/as an alternative to/

Third bullet:
The bullet on host-scanning needs some justification.

Fourth bullet:  This is not a security issue.
Paragraph after bullets:
s/algorithm is meant to replace/meant to supplement/

Best regards and Merry Christmas,
Bob and Ole

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Thu, 20 Dec 2012 22:06:23 +0100

Ole and Bob: I don't think that the extension to the Privacy Extension RFC is applicable here.

Fernando:

I think some of these comments were also made by Ole and Bob but, as I was so busy, I could not finish them and send them.

Now the question is whether or not you are using the "lifetime" for this IID or IP. If you are, then it is the same procedure as that for the RFC privacy extension.

>Nobody has even suggested this. For instance, if these addresses had a lifetime (in the RFC4941 sense), they wouldn't be called "stable" in the first place.
I understand that you did not use a lifetime for the address where the privacy, within the network, is questionable! I said that, if you are really concerned about privacy, then you would need to set the lifetime for your address, even within the same subnet.

When you use the same, so called stable addresses, in the same subnet,  it means that you generate the same address and use the same address forever within that subnet. Now the question is, if your address ,according to your draft, does not change, what privacy protection is afforded within the network here? Especially for those fixed nodes, within that network, that never move to another network.

The second question: usually when, for privacy reasons, ISPs change their addresses they also change the prefixes. So as you say you generate new address for the new prefix, what is the stability of the address?

For the Second concern, let's go back to the privacy extension RFC. As I mentioned in a prior email, the second approach is to use  CGA or DHCPv6. But they did not explain how to do this. They mentioned CGA as a way for generating a  random IID but did not mention it as a security option. So one might consider extending that section to include an explanation  as to how to use the second approach in that RFC. For example, suggest using the CGA generation algorithm (as you are using it with another name!) and since the address does not need to be verified, then there is no need to set a sec value or add CGA options to the options in SEND. Another suggestion might  that there is no need for the other node to process verification because security is not an issue.
> * In 3972, there's no secret. Hence, the attacker might be able to compute the IID himself (assuming the algorithm and the input parameters are known).
Not true as I pointed out before.
> * If the CGA Modifier changes (as they are supposed to), then the addresses are not constant within the same network (each time you generate a CGA, the IID would be different).
See my first paragraph as a response to this.

As I pointed out before, one can make improvements to the privacy extension RFC and explain the second approach, in more detail for the use of the same algorithm in CGA as was used (the same as sec value 0, i.e., you just run the hash algorithm once on the concatenation of a random number, subnet prefix and etc) and skip the verification mechanism since no verification is needed.
> As noted above, many deployments turn off privacy addresses.
I do not think this is a good reason in this case because they can also do the same thing using your draft proposal and never implement it, or disable it!

>A.1.3.  Revealing the identity of devices performing server-like

        Functions
Some devices need to have a fix IP address and these are usually set by an administrator manually or a fixed range of IP address for the devices being used. This is what happens in large networks. In small networks, like home networks, usually the name of the devices are used. For some servers or server functioning devices, privacy is not important because they should be available and well known in that network. So for those well-known devices, privacy does not make sense.

Finally, in your draft you do not completely address the privacy issue. When the same network is used to connect different places, then your node becomes vulnerable to tracking. What I think is, as long as you think about stability, that you need to also forget about  privacy. And if you decide to be concerned with privacy, then you need to use a lifetime for your address. This is again like the privacy extension RFC, and so, your draft can be written to improve the second approach described in that RFC as I do not think stability can solve the privacy issues. At the beginning privacy related attacks might decreased, but when you plan to use that IP from the same subnet forever, then you are vulnerable to those types of attack. The attacker only needs to spend more time gathering information about that node. Then, after a while, it will be easy for him to track that node again. This means, with your way, the attacks are still possible; you have just postponed the attacks between networks but done nothing for those inside the same network.

Thank you,
Hosnieh

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: Thursday, December 20, 2012 3:41 PM
To: 6man 6man-wg
Subject: Chairs review: draft-ietf-6man-stable-privacy-addresses-01

all,

General comments:

Major points:
-----------------

- The algorithm in the document  is underspecified.
  o It should specify the hash function. E.g. MD5 as RFC4941.
  o It should handle reserved interface-ids (see 4941).
  o We suggest renaming the "secret key" to "modifier". And add text describing
    how to 'maintain' the modifier (section 3 of RFC3972).
  o It would be useful to include an example algorithm as has been done in some other documents.
  o Not all implementations use interface indexes

Minor points:
-----------------

Third bullet:

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Dec 2012 16:23:01 -0300

Bob, and Ole,

Thanks so much for your detailed review! Please find my comments in-line....

> General comments:

I disagree. Could you please mention what's in RFC4941 that results in
addresses that are stable within the same subnet, but different across
subnets?

> with lifetime handling as for SLAAC, or as an extension to CGA (RFC3972)
> address generation where the public key is removed from the hash. 

Isn't the whole point of CGAs to have the hash be computed over the
public key?

> The method for generating "Stable privacy addresses" needs to be as well
> specified as temporary addresses (RFC4941).
> We do wonder if the method of generating these addresses could be a
> modification of the algorithm in RFC4941, or if at least, larger parts of 
> the text in RFC4941 could be

Hasn't this be discussed to death during the year? (particularly in the
Paris IETF -> Vancouver IETF) time frame. For instance, as noted above,
RFC 4941 addresses do not have the location-related properties of these
addresses.

> We do not believe the current revision of the document is ready to

Good point. This wording is simply an error (text that remained from the
time I meant these addresses to replace the RFC 2464 ones).

>   o It should specify the hash function. E.g. MD5 as RFC4941.

Why should it? Put another way, is this needed for the algorithm to
work? -- it's not.

IMO, we might RECOMMEND some algorithm, or note that nodes MAY use this
or that algorithm... But requiring a specific one seems like
over-specifying the algorithm.

>   o It should handle reserved interface-ids (see 4941).

Good point, will do.

>   o We suggest renaming the “secret key” to “modifier”. And add text
> describing how to ‘maintain’ the modifier (section 3 of RFC3972).

It is not a modifier... it is a *secret key*. And this is key (no pun
intended :-) ) for the algorithm to behave as expected: if the key is
known by the attacker, he could compute the IID himself.

>   o It would be useful to include an example algorithm as has been done

You mean as in RFC4941? Or a algorithm in pseudo-code?

>   o Not all implementations use interface indexes

How do you identify interfaces without "indexes"/names of some form?

> - Clarify what lifetimes these addresses have.

You mean lifetimes in the sense of "same thing as tradtional slaac
addresses" or lifetime in the sense of "the address will be stable as
long as you don't change the secret key".

> - Specify the default for DAD retries (IDGEN_RETRIES)

Will do.

> - Clarify the requirements for stable storage (compared to RFC2464)

This is, to a large extent, optional. I guess we could get away with
"hosts MAY..."?

> Minor points:

Good point. Will do.

> leak regardless, in other communication, email header etc.

Ok.

> s/in replacement of/as an alternative to/

Good grief. Will do

> The bullet on host-scanning needs some justification.

Can we get away with it by referencing draft-ietf-opsec-ipv6-host-scanning?

> Fourth bullet:  This is not a security issue.

Which one?

> s/algorithm is meant to replace/meant to supplement/

Yup. Will fix this one, too.

Thanks! ... and Merry Christmas! ;-)

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

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Dec 2012 18:29:00 -0300

Hosnieh,

On 12/20/2012 06:06 PM, Rafiee, Hosnieh wrote:
> Now the question is whether or not you are using the "lifetime" for this
> IID or IP. If you are, then it is the same procedure as that for the RFC
> privacy extension.

The lifetime advertised in RA messages? - Of course.

> I understand that you did not use a lifetime for the address where the
> privacy, within the network, is questionable! I said that, if you are
> really concerned about privacy, then you would need to set the lifetime
> for your address, even within the same subnet.

This addresses are *stable*. As noted in RFC4941, you usually need some
stable address, even if you do RFC4941.

> When you use the same, so called stable addresses, in the same subnet, 
> it means that you generate the same address and use the same address
> forever within that subnet. Now the question is, if your address
> ,according to your draft, does not change, what privacy protection is
> afforded within the network here? 

You cannot be tracked across networks.

> The second question: usually when, for privacy reasons, ISPs change
> their addresses they also change the prefixes. So as you say you
> generate new address for the new prefix, what is the stability of the
> address?

If the prefix changes, then from an IP-layer point of view, you're
connected to a different network.

> For the Second concern, let's go back to the privacy extension RFC. As I
> mentioned in a prior email, the second approach is to use  CGA or
> DHCPv6. But they did not explain how to do this. They mentioned CGA as a
> way for generating a  random IID but did not mention it as a security
> option. So one might consider extending that section to include an
> explanation  as to how to use the second approach in that RFC. For
> example, suggest using the CGA generation algorithm (as you are using it
> with another name!) and since the address does not need to be verified,
> then there is no need to set a sec value or add CGA options to the
> options in SEND. 

Well, yeah... at which point, that's not CGAs anymore. ;-)

> Another suggestion might  that there is no need for the
> other node to process verification because security is not an issue.

Where?

> As I pointed out before, one can make improvements to the privacy
> extension RFC and explain the second approach, in more detail for the

RFC4941 produces random addresses. Period. It's a different scheme, with
different objetives.

> use of the same algorithm in CGA as was used (the same as sec value 0,
> i.e., you just run the hash algorithm once on the concatenation of a
> random number, subnet prefix and etc) and skip the verification
> mechanism since no verification is needed.

At which point you should strip most of the CGA document, since most of
its contents is related with something else.

i.e., we can play the game of "how could I tweak/strech this or that RFC
so that we get to the same behavior".. but I'm not sure whatd be the
benefit of that.

> I do not think this is a good reason in this case because they can also
> do the same thing using your draft proposal and never implement it, or
> disable it!

The reasons for which they disable RFC4941 do not apply to
draft-ietf-6man-stable-privacy-addresses.

> Some devices need to have a fix IP address and these are usually set by
> an administrator manually or a fixed range of IP address for the devices
> being used. This is what happens in large networks. In small networks,
> like home networks, usually the name of the devices are used. For some
> servers or server functioning devices, privacy is not important because
> they should be available and well known in that network. So for those
> well-known devices, privacy does not make sense.

That doesn't mean they should be easily discoverable from the public
Internet or the like.

> Finally, in your draft you do not completely address the privacy issue.
> When the same network is used to connect different places, then your
> node becomes vulnerable to tracking. What I think is, as long as you
> think about stability, that you need to also forget about  privacy.

Huh? If you connect to two different subnets, the prefix is different,
and hence the resulting IID is different.

> And
> if you decide to be concerned with privacy, then you need to use a
> lifetime for your address. This is again like the privacy extension RFC,

RFC4941 addresses are generated **in addition** to the traditional slaac
addresses. RFC4941 does nothing to mitigate the implications of
traditional slaac addresses. And that's what this i-d is meant to do.

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

---

From: Ole Troan <[email-masked]>
Date: Fri, 21 Dec 2012 12:20:32 +0100

Fernando,

> addresses that are stable within the same subnet, but different across

an _extension_ to RFC4941.
two options come to mind, include the prefix in the hash used in 4941 for these addresses,
or just use the 4941 algorithm with RA lifetimes, and require that the node stores the resulting addresses.
that nodes should remember the address they used on previous links is already covered in RFC 4862 I believe.
the latter mechanism doesn't work well for nodes without persistent storage though.

> Isn't the whole point of CGAs to have the hash be computed over the

the suggestion was you can achieve stable privacy addresses also as an extension of the text in RFC3972.

> RFC 4941 addresses do not have the location-related properties of these

see above. we think the method must be as well specified as the 4941 method is,
that may result in some redundant text, which is why we suggested if you had looked
at making it an extension instead of a entirely separate document.
(note that this was a question, I don't know the right answer).

> over-specifying the algorithm.

could you use similar text as 4941?
there might actually be some benefit in two nodes given the same secret key/modifier
creates the same address(?)

> known by the attacker, he could compute the IID himself.

could it not be some unique number the implementation has?
serial number, MAC address, etc?
if it has to be a secret key, and it has to be provisioned, then mightn't you as well use 3972 addresses?

> You mean as in RFC4941? Or a algorithm in pseudo-code?

as in 4941.

> How do you identify interfaces without "indexes"/names of some form?

in IOS we do pass pointers around. ;-)
well, we do have indexes and names too.

> long as you don't change the secret key".

an address cannot have a longer lifetime than the lifetimes advertised in RAs of course.
could you say something along the lines of: Stable Privacy Addresses have the same lifetime properties
as SLAAC addresses [4862] and expire as described in section 5.5.3 of 4862.

> This is, to a large extent, optional. I guess we could get away with

wouldn't you behave differently, e.g. if the node has no persistent storage for a secret key?

>> s/in replacement of/as an alternative to/

;-)

> Can we get away with it by referencing draft-ietf-opsec-ipv6-host-scanning?

yes, that would probably work.

>> Fourth bullet:  This is not a security issue.

must have meant third bullet.

> Thanks! ... and Merry Christmas! ;-)

thanks, and to you too!
off on holiday now!

best regards,
Ole

---

From: "Rafiee, Hosnieh" <[email-masked]>
Date: Fri, 21 Dec 2012 15:23:30 +0100

Fernando,
As we have seemed to reach a stalemate in this discussion, I see no need for continuing it. I tried to explain everything in my last emails and I see no point in reiterating it here. I offered you a different approach which I feel would allow you to continue with an RFC. you might want to investigate this.

Thank you,
Hosnieh

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Donnerstag, 20. Dezember 2012 22:29
To: Rafiee, Hosnieh
Cc: Fernando Gont ([email-masked]); Bob Hinden ([email-masked]); [email-masked]
Subject: Re: Chairs review: draft-ietf-6man-stable-privacy-addresses-01

Hosnieh,

On 12/20/2012 06:06 PM, Rafiee, Hosnieh wrote:
> Now the question is whether or not you are using the "lifetime" for 
> this IID or IP. If you are, then it is the same procedure as that for 
> the RFC privacy extension.

> really concerned about privacy, then you would need to set the 
> lifetime for your address, even within the same subnet.

This addresses are *stable*. As noted in RFC4941, you usually need some stable address, even if you do RFC4941.

> generate new address for the new prefix, what is the stability of the 

If the prefix changes, then from an IP-layer point of view, you're connected to a different network.

> For the Second concern, let's go back to the privacy extension RFC. As 
> I mentioned in a prior email, the second approach is to use  CGA or 
> DHCPv6. But they did not explain how to do this. They mentioned CGA as 
> a way for generating a  random IID but did not mention it as a 
> security option. So one might consider extending that section to 
> include an explanation  as to how to use the second approach in that 
> RFC. For example, suggest using the CGA generation algorithm (as you 
> are using it with another name!) and since the address does not need 
> to be verified, then there is no need to set a sec value or add CGA 
> options to the options in SEND.

> Another suggestion might  that there is no need for the other node to 
> process verification because security is not an issue.

>>Where?
The Last two emails

> extension RFC and explain the second approach, in more detail for the

RFC4941 produces random addresses. Period. It's a different scheme, with different objetives.

> mechanism since no verification is needed.

At which point you should strip most of the CGA document, since most of its contents is related with something else.

i.e., we can play the game of "how could I tweak/strech this or that RFC so that we get to the same behavior".. but I'm not sure whatd be the benefit of that.

> I do not think this is a good reason in this case because they can 
> also do the same thing using your draft proposal and never implement 
> it, or disable it!

The reasons for which they disable RFC4941 do not apply to draft-ietf-6man-stable-privacy-addresses.

> Some devices need to have a fix IP address and these are usually set 
> by an administrator manually or a fixed range of IP address for the 
> devices being used. This is what happens in large networks. In small 
> networks, like home networks, usually the name of the devices are 
> used. For some servers or server functioning devices, privacy is not 
> important because they should be available and well known in that 
> network. So for those well-known devices, privacy does not make sense.

That doesn't mean they should be easily discoverable from the public Internet or the like.

> think about stability, that you need to also forget about  privacy.

Huh? If you connect to two different subnets, the prefix is different, and hence the resulting IID is different.

> lifetime for your address. This is again like the privacy extension 

RFC4941 addresses are generated **in addition** to the traditional slaac addresses. RFC4941 does nothing to mitigate the implications of traditional slaac addresses. And that's what this i-d is meant to do.

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 21 Dec 2012 12:47:22 -0300

> an _extension_ to RFC4941.

IMO, that's stretching things too much. IMO, *stable-privacy-addresses
have nothing to do with RFC 4941.

That said, this was already discussed at the Paris IETF timeframe, and
the wg had agreed on the current approach. IMHO, I'd expect that we
focus on the current I-D, than rehash 8+months-settled discussions.
Particularly at this point in time.

> two options come to mind, include the prefix in the hash used in 4941 for these addresses,

The only thing that stable-privacy-addresses have in commong with
RFC4941 is that they employ a hash function. But lots of things use
hashes these days. Also, then we should have argued that rfc4941 should
have been published as an extension to CGAs (or the other way around...
whatever came first). -- which would have certainly not been sensible to do.

> or just use the 4941 algorithm with RA lifetimes, and require that the node stores the resulting addresses.

That's, of course, a non-starter.

> the suggestion was you can achieve stable privacy addresses also as an extension of the text in RFC3972.

Same as above applies. Also, you don't want an implementer to go through
30 pages, understand that stuff, and then say "now forget about these 28
pages, forget about the whole public key thing [etc].. and focus on this
expression"

> see above. we think the method must be as well specified as the 4941 method is,

Can you clearly state why? -- IMO, RFC4941 is overspecified. Some device
might choose to do MD5. Some other might choose to do SHA-1... some
embedded device other might want to use a crappy function just to avoid
using IEEE OUIs.

We should specify additional requirements when that affects
interoperability. Adding additional requirements n terms of crypto
algorithms seems unnecessary to me.

> (note that this was a question, I don't know the right answer).

I disagree with that approach. For instance, the "algorithm" vils down to:

1) If you hae recorded an address for this network, use it.

2) Compute the IID for this entwork

3) Chec for special addresses, and go back to 4 if wrong

4) Do DAD, and go back to 2 if it fails.

> creates the same address(?)

IMO, the drawbacks outweigh the benefits. If we require an algorithm,
we're stuck with that algorithm forever (because if we ever change it,
the "the same secret key/modifier creates the same address" argument is
void).

OTOH, if we don't require any specific algorithm, implemenrarions are
free to use whatever fits them, and make their own decisions when it
comes to tradeoffs in security, processing power, simplicity to
implement, etc.

That aside, ass a vendor you're free to employ the same algorithm in all
your products, such that if one box gets replaced by another one, you
get the same address.

> if it has to be a secret key, and it has to be provisioned, then mightn't you as well use 3972 addresses?

A secret key is a value that is... secret. Whether its randmly
generated, provided by the admin, or whatever, is irrelevant.

The reason why this parameter is called secret key is because that's its
most important property... and if the secret key is not secret, then the
benefits of the algorithm are gone.

So the only sensible change here would kind of be s/secret/SECRET/ to
stress this fact.

>> You mean as in RFC4941? Or a algorithm in pseudo-code?

I've sketched it above. Please let me know if that one addresses your
concerns.

> in IOS we do pass pointers around. ;-)

Then you do have interface indexes. The relevant spec doesn't require
any specific form of indexes.. they could be names, numbers, pinters, or
whatever you want, since that doesn't affect interoperability with other
implementations.

(which is yet another example of the "rationale" I've applied here when
not overspecifying stable-privacy-addresses).

> well, we do have indexes and names too.

All implementations have (of some form or another).

> as SLAAC addresses [4862] and expire as described in section 5.5.3 of 4862.

Will do. (this was implicit, anyway, since we're just generating IIDs
for slaac in a different way, but *not* changing slaac itself).

>>> - Specify the default for DAD retries (IDGEN_RETRIES)

Actually... why should we specify this. IMO, we should just say "Do
DAD". And whatever that means should apply.

> wouldn't you behave differently, e.g. if the node has no persistent storage for a secret key?

The only difference is the obvious one: if you do have stable storage,
before generating an address you should look whether you have an address
for this network in stable storage. And when you configure an address,
you should store it in stable storage. Period.

Me, I don't expect any implementations use stable storage for this.

Thanks!

Best regards.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Dec 2012 06:13:30 -0300

On 12/21/2012 11:23 AM, Rafiee, Hosnieh wrote:
> Fernando, As we have seemed to reach a stalemate in this discussion,
> I see no need for continuing it. I tried to explain everything in my
> last emails and I see no point in reiterating it here.

90% of your feedback was about how other RFCs could be tweaked/stretched
to acommodate stable-privacy-addresses. And that included taking the
CGAs RFC, and throwing 80%-90% of it, and include new stuff to make it
do something that CGA addresses were not meant to do. IMO, that's not a
sensible thing to do. (Not to mention the fact that IIRC there are IPRs
on CGAs... s the further we stay from there, the better).

> I offered you
> a different approach which I feel would allow you to continue with an
> RFC. you might want to investigate this.

This I-D is a g item, which this wg adopted ~9 months ago. I'm not sure
why you could argue that we should follow your proposed approach,
instead of the one we got consensus on.

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 29 Dec 2012 20:33:04 -0300

Hi, Ole,

I've rev'ed the I-D according to your feedback and our recent email
exchange. Some additional notes below:

On 12/21/2012 08:20 AM, Ole Troan wrote:
[discussion of what this algorithm is similar to]

FWIW, I've added an ack to the Acks section, noting that this algorithm
was inspired by Steve Bellovin's work on TCP sequence numbers. For
instance, what this algorithm does is to separate the IID-space on a
"per-network" basis.

>> Why should it? Put another way, is this needed for the algorithm to

I've added some text in this area -- noting why we do not require any
specific algorithm.

>> You mean as in RFC4941? Or a algorithm in pseudo-code?

RFC 4941 needs an algorithm because it is more complex than this IID. As
far as this alg is concerned, the only algorithm one could come up with is:

1) generate the IID with this expression
2) tweak the U/G bit
3) Check for reserved addresses, and consider this a DAD conflict if it
is a reserved address

DAD shouldn't be included in this "algorithm" because we're not updating
RFC4862 at all. -- we're just specifying an alternative algorithm for
generating IIDs.

> as SLAAC addresses [4862] and expire as described in section 5.5.3 of 4862.

I've clarified this. However, I should note that there's no reason to
believe that these lifetimes change, since we're not changing SLAAC (RFC
4862).

>>> - Specify the default for DAD retries (IDGEN_RETRIES)

I did specify this -- however, IMHO this is out-of-scope, since this
value should be specified somewhere else.

Please check the rev'ed I-D -- I believe it is ready to ship.

Thanks so much, and have a Happy New Year!

Best regards,