Subject: Re: [dhcwg] draft-ietf-6man-default-iids Section 4 & 6.9 (DHCPv6)

From: Alissa Cooper <[email-masked]>
Date: Thu, 4 Aug 2016 13:23:16 -0700

> On Jul 21, 2016, at 1:58 AM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> Ole:
> 
> (I fixed 6man mailing list address.)
> 
> That is probably the best solution and I would support that.
> 
> We can still discuss changing some of the text in 3315bis, but that can
> then be done without 6man involvement. (We do still have the older text in
> what is now Section 12.1 of draft-ietf-dhc-rfc3315bis-05, so should really
> clean that up.)

I am fine with this solution and it seems cleaner.

Alissa

> 
> - Bernie
> 
> 
> On 7/21/16, 4:45 AM, "[email-masked]" <[email-masked]> wrote:
> 
>> Bernie, et al,
>> 
>> The first line of the abstract says:
>>  "This document changes the recommended default IID generation scheme
>>  for cases where SLAAC is used to generate a stable IPv6 address."
>> 
>> I'm not convinced that we need to have the DHCP paragraph there at all.
>> Would that work for you?
>> 
>> Best regards,
>> Ole
>> 
>> 
>>> On 21 Jul 2016, at 10:30, Bernie Volz (volz) <[email-masked]> wrote:
>>> 
>>> Alissa, et al:
>>> 
>>> Based on a conversation between some of the draft-ietf-dhc-rfc3315bis
>>> coauthors and in the DHC WG session Wednesday (7/20) morning, we are not
>>> in favor of the replacement text as it currently stands. We will work
>>> something up and send it to you as soon as we can.
>>> 
>>> We are likely to simplify the replacement text to something like the
>>> following (but this is only my proposal and has not been reviewed by
>>> others):
>>> 
>>>    By default, DHCPv6 server implementations SHOULD NOT generate
>>>    predictable IPv6 addresses ([RFC7721]). DHCPv6 servers SHOULD
>>>    NOT assign addresses that use a reserved IPv6 Interface Identifier
>>>    ([RFC5453], [RFC7136], and [IANARESERVEDIID]).
>>> 
>>> We are tracking this issue at
>>> https://trac.tools.ietf.org/group/dhcpv6bis/ticket/166.
>>> 
>>> - Bernie
>>> _______________________________________________
>>> dhcwg mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dhcwg
>> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Fernando Gont <[email-masked]>
Date: Fri, 5 Aug 2016 14:41:53 +0200

> I am fine with this solution and it seems cleaner.

Background: At some point folks argued that this document should cover
SLAAC, DHCPv6, and manual configuration. And hence this text was added.

I don't mind removing the DHCPv6 text. However, if we do, we should
probably also remove the text about manual configuration. Otherwise it
is not clear why some forms of configuration are covered, but others are
not.

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Aug 2016 11:17:03 +1000

> is not clear why some forms of configuration are covered, but others are

I argued for that because I think privacy is a primary property of an
address, not the method used to configure it. However, since the different
methods of configuring the address can effect the resulting address's
privacy properties, I think it is necessary to discuss how to achieve
privacy for the three different configuration methods we have in the one
place.

Regards,
Mark.

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

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 9 Aug 2016 11:49:14 -0700

> On Aug 5, 2016, at 6:17 PM, Mark Smith <[email-masked]> wrote:
> 
> 
> On 5 Aug 2016 22:42, "Fernando Gont" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > >> On Jul 21, 2016, at 1:58 AM, Bernie Volz (volz) <[email-masked] <mailto:[email-masked]>> wrote:
> > >>
> > >> Ole:
> > >>
> I argued for that because I think privacy is a primary property of an address, not the method used to configure it. However, since the different methods of configuring the address can effect the resulting address's privacy properties, I think it is necessary to discuss how to achieve privacy for the three different configuration methods we have in the one place.
> 
> 

As far as what the resulting privacy properties of an address are, I can see one overview document being useful. But I could see value in the scope of that being broader (to also cover, say, temporary addresses) and writing that after the separate specs about how to do configuration have stabilized, assuming the DHCP bit moves into 3315bis.

Alissa
> Regards,
> Mark.
> 
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>

---

From: [email-masked]
Date: Wed, 10 Aug 2016 10:16:32 +0200

Mark,

[...]

> I argued for that because I think privacy is a primary property of an address, not the method used to configure it. However, since the different methods of configuring the address can effect the re…

And you don't think RFC7721 is enough?

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Aug 2016 18:28:56 +1000

> And you don't think RFC7721 is enough?

Yes, got this draft and that RFC mixed up! I think I missed that RFC
getting published, which is why I thought that sort of text was in a
draft somewhere.

Apologies for the noise!

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 10 Aug 2016 21:21:57 +1000

> getting published, which is why I thought that sort of text was in a

Actually I'll take that back. RFC7721 is analysis of the issues.

draft-ietf-6man-default-iids is really about SLAAC and DHCPv6 as they
computer generate IIDs.

My suggestion to also include static IIDs was more as a related side
note (not sure if there is anyway to indicate that in an RFC), as I
think having a bit of advice on static IIDs somewhere would be useful
(a separate RFC might be a bit excessive). The title is general enough
that I think static IIDs advice can be included, and it then makes
this ID cover all current methods of configuring addresses.

Regards,
Mark.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 10 Aug 2016 11:35:44 +0000

For DHCPv6 we already have information about this in https://tools.ietf.org/html/rfc7824#section-4.3. And we have an open ticket to modify text in the 3315bis document -- https://trac.tools.ietf.org/group/dhcpv6bis/ticket/166.

- Bernie (from iPad)

>> On Aug 10, 2016, at 7:22 AM, Mark Smith <[email-masked]> wrote:
>>