Hi Tim,
----- Original Message ----- > From: Tim Chown <[email protected]> > To: Fernando Gont <[email protected]> > Cc: Mark ZZZ Smith <[email protected]>; "[email protected] > Chairs" <[email protected]>; 6man WG <[email protected]> > Sent: Friday, 23 August 2013 8:56 PM > Subject: Re: 6MAN WG Last Call: <draft-ietf-6man-stable-privacy-addresses-12> > > On 22 Aug 2013, at 22:58, Fernando Gont <[email protected]> wrote: > >> On 08/19/2013 08:19 AM, Mark ZZZ Smith wrote: >>> >>> Going by the title, it seems my comment was missed about not implying >>> that this address generation technique is limited to SLAAC slack >>> scenarios, but could be useful with any address configuration method >>> (i.e, SLAAC, DHCPv6, static, +future.) There seemed to be some >>> support for decoupling the concepts of address generation from >>> address configuration. >> >> How about something like: >> >> "While the method specified in this document is meant to be used with >> SLAAC, this doesn not preclude the same algorithm from being used with >> other address configuration mechanisms, such as DHCPv6 or static address >> confguration" >> >> at the end of Section 1, right before the "terminology" > paragraph? > > I think that fits well with the advice in 5177 and its replacement to not use > sequential IPs from a DHCP pool. > > The difference for DHCP is perhaps that there may be some reason the pool is > not > the whole /64, in which case it would still be prudent to randomise from > within > the pool. > > I think Mark's point though is that an address may be used for the > initiation of incoming and/or outgoing communications, and how the address is > generated should not necessarily be tied to how it is used. I would certainly > agree with that. > Not quite. I'm more coming from the point of view that generally address generation methods are or should be separate from address configuration methods (although influenced by them if necessary or useful), and neither of the methods should influence address expiry - IPv6 preferred and valid lifetimes are for that. The reason I've been thinking about this is the recent identified behaviour in Windows where when the M bit was switched off in an RA, the Windows machine would tear down stateful DHCPv6 and immediately expire the IPv6 addresses that were configured by it, even though the addresses themselves still had non-zero valid and preferred lifetimes. This behaviour would prevent a smooth transition on a link from SLAAC address configuration to stateful DHCPv6 and vice-versa. So it has seemed to me there are really 3 separate addressing related functions: - address generation methods (e.g., derived from IEEE address, the method described in this ID, or others) - address configuration methods, that configure addresses and their preferred and valid lifetime values (currently SLAAC, stateful DHCPv6 or static) - the address expiring/aging method, using the preferred and valid lifetimes, but should not influenced by the method used to configure them (if you want to force address expiry, use your chosen address configuration method to set the preferred and valid lifetimes to their expiry values and then let the addresses immediately age out) By keeping the address expiring/aging method independent from the address configuration method, it would then be possible to fairly smoothly transition between different address configuration methods, rather than the current disruption that would be suffered with Windows (and perhaps other OSes) today. The above text is motivated by the idea that the addresses generated by the method described in the draft should be possible to configure using SLAAC, stateful DHCPv6 or manual static configuration, or any other future address configuration methods. This draft is describing both an address generation method and how the generated addresses can be configured using SLAAC. The proposed text leaves room to describe how the address generation method could be used with stateful DHCPv6 or just applied with static configuration if the addresses are generated manually (using a script, spreadsheet etc.). Off-list I suggested rather than a future draft specifying how to use the provided address generation method with DHCPv6, have a future draft called something like "A Generalised Method for Generating Semantically Opaque IPv6 Interface Identifiers", which might discuss how they can be used with DHCPv6 as a configuration method, but hopefully general enough that if there are future address configuration methods, they don't need to specify how Semantically Opaque IPv6 Interface Identifiers are configured with them. > I'm not sure what you mean by static address configuration in this context. > Is it clearer now? Regards, Mark. > Tim > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
