%% You should probably cite rfc8064 instead of this I-D.
@techreport{ietf-6man-default-iids-06,
    number =    {draft-ietf-6man-default-iids-06},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/06/},
    author =    {Fernando Gont and Alissa Cooper and Dave Thaler and Will (Shucheng) LIU},
    title =     {{Recommendation on Stable IPv6 Interface Identifiers}},
    pagetotal = 10,
    year =      2015,
    month =     aug,
    day =       19,
    abstract =  {The IPv6 addressing architecture defines Modified EUI-64 format Interface Identifiers, and the existing IPv6 over various link-layers specify how such identifiers are derived from the underlying link- layer address (e.g., an IEEE LAN MAC address) when employing IPv6 Stateless Address Autoconfiguration (SLAAC). The security and privacy implications of embedding link-layer addresses in the Interface Identifier have been known and understood for some time now, and some popular IPv6 implementations have already deviated from such schemes to mitigate these issues. This document changes the recommended default Interface Identifier generation scheme for SLAAC to that specified in RFC7217, and recommends against embedding link- layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC4944, RFC5072, and RFC5121, which require IPv6 Interface Identifiers to be derived from the underlying link-layer address. Additionally, this document provides advice about the generation of Interface Identifiers with other address configuration mechanisms, such as Dynamic Host Configuration Protocol version 6 (DHCPv6) and manual configuration.},
}