Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt

[Mark ZZZ Smith <[e-mail]>]

Hi Fernando,


----- Original Message -----
> From: Fernando Gont <[e-mail]>
> To: Mark ZZZ Smith <[e-mail]>; "[e-mail]" <[e-mail]>; "[e-mail]" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Sent: Wednesday, 19 February 2014 4:58 AM
> Subject: Re: I-D Action: draft-ietf-6man-ipv6-address-generation-privacy-01.txt
> 
> On 02/15/2014 12:37 AM, Mark ZZZ Smith wrote:
> 
>> 
>>  I think it would be useful to not specifically couple address
>>  configuration methods (SLAAC, DHCPv6, static/manual) with address
>>  generation methods (MAC derived, RFC4941, cryptographically generated
>>  etc.). I think what is being discussed about addresses equally
>>  applies regardless of the address configuration method used to
>>  configure the resulting IPv6 address on an interface.
> 
> Makes sense -- although for the most part, they do seem to be coupled in
> practice.
> 

I think that has been a coupling of "convenience" more than a necessity. I think it is also the origin of the issues where when DHCPv6 or SLAAC is switched off on a link, the DHCPv6 or SLAAC configured addresses have been removed from the hosts' interfaces, even though the addresses still had valid lifetimes. I've come to the belief that the only address expiry mechanism is their lifetimes, and the lifetimes, while set by the address configuration method used, are the only determinant of whether the address should be expired or not.



> 
> e.g., how do you do CGAs with DHCPv6, etc.?
> 
> It seems to me that while there's a distinction between the mechanism
> used for address configuration and the resulting IID, for most cases
> there's a 1 to 1 mapping... and it's valuable how such IIDs are
> typically generated.
> 

I'm not sure there is a 1:1 mapping very often, though it might be implied by the various RFCs that have coupled them together. However, if you go through a variety of examples of IID generation methods, and think of the methods that can or could be used to configure them, most of the time they aren't very exclusive.

For example, privacy addresses can be configured via SLAAC or via DHCPv6 (IA_TA option). The could also be configured manually, by generating the address and then setting non-infinite lifetimes. So the privacy address generation mechanism isn't coupled to a single address configuration method.

As another example, consider EUI-64 derived. Used by SLAAC, however I don't think there is any technical reason why a DHCPv6 server couldn't generate addresses based on the EUI-64 form of the link-layer source address the host used, and then dole them out to the hosts. They could be configured manually too.

I thought the same for your Opaque IDs address generation method, which is why I suggested the text to say that this method isn't exclusively tied to SLAAC. DHCPv6 servers could use the opaque IID address generation method, and it could also be used to generate addresses that are then manually configured on the host (perhaps via a boot script).

I agree there are some cases where the address generation and address configuration methods are tightly coupled, such as your CGA with DHCPv6 example. However I think they're the exception rather than the rule, which is why I think there is value in treating address generation as a distinct function that is usually separate from address configuration. (In summary, I think there are 3 distinct addressing related functions - address generation (privacy, opaque, EUI-64), address configuration (SLAAC, DHCPv6, static/manual) and address expiry (valid lifetime)). 


Regards,
Mark.


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