One document matched: draft-ietf-6man-ipv6-address-generation-privacy-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="no" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1972 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1972.xml'>
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2462 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2462.xml'>
<!ENTITY RFC2464 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2464.xml'>
<!ENTITY RFC3041 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3041.xml'>
<!ENTITY RFC3314 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3314.xml'>
<!ENTITY RFC3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY RFC3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY RFC3971 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml'>
<!ENTITY RFC3972 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml'>
<!ENTITY RFC4380 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4380.xml'>
<!ENTITY RFC4941 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4941.xml'>
<!ENTITY RFC5991 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5991.xml'>
<!ENTITY RFC6265 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6265.xml'>
<!ENTITY RFC6724 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6724.xml'>
<!ENTITY RFC6973 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml'>
]>
<rfc category="info" ipr="trust200902" docName="draft-ietf-6man-ipv6-address-generation-privacy-01.txt">
<front>
<title abbrev="IPv6 Address Generation Privacy">Privacy Considerations for IPv6 Address Generation Mechanisms</title>
<author initials="A." surname="Cooper" fullname="Alissa Cooper">
<organization>Cisco</organization>
<address>
<postal>
<street>707 Tasman Drive</street>
<city>Milpitas</city>
<region>CA</region>
<code>95035</code>
<country>US</country>
</postal>
<phone>+1-408-902-3950</phone>
<email>alcoop@cisco.com</email>
<uri>https://www.cisco.com/</uri>
</address>
</author>
<author
fullname="Fernando Gont"
initials="F."
surname="Gont">
<!-- abbrev not needed but can be used for the header
if the full organization name is too long -->
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Evaristo Carriego 2644</street>
<code>1706</code><city>Haedo</city>
<region>Provincia de Buenos Aires</region>
<country>Argentina</country>
</postal>
<phone>+54 11 4650 8472</phone>
<email>fgont@si6networks.com</email>
<uri>http://www.si6networks.com</uri>
</address>
</author>
<author
fullname="Dave Thaler"
initials="D."
surname="Thaler">
<organization>Microsoft</organization>
<address>
<postal>
<street>Microsoft Corporation</street>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
</postal>
<phone>+1 425 703 8835</phone>
<email>dthaler@microsoft.com</email>
</address>
</author>
<date year="2014"/>
<abstract>
<t>This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>IPv6 was designed to improve upon IPv4 in many respects, and
mechanisms for address assignment were one such area for improvement.
In addition to static address assignment and DHCP, stateless
autoconfiguration was developed as a less intensive, fate-shared means
of performing address assignment. With stateless autoconfiguration,
routers advertise on-link prefixes and hosts generate their own
interface identifiers (IIDs) to complete their addresses. Over the years, many interface identifier
generation techniques have been defined, both standardized and non-standardized:</t>
<t><list style='symbols'>
<t>Manual configuration
<list style='symbols'>
<t>IPv4 address</t>
<t>Service port</t>
<t>Wordy</t>
<t>Low-byte</t>
</list>
</t>
<t>Stateless Address Auto-Cofiguration (SLAAC)
<list style="symbols">
<t>IEEE 802 48-bit MAC or IEEE EUI-64 identifier <xref target="RFC1972" /><xref target="RFC2464" /></t>
<t>Cryptographically generated <xref target="RFC3972"/>
</t>
<t>Temporary (also known as "privacy addresses")<!-- <xref target="RFC3041" /> --> <xref target="RFC4941" /></t>
<t>Constant, semantically opaque (also known as random) <xref target="Microsoft" /></t>
<t>Stable, semantically opaque <xref target="I-D.ietf-6man-stable-privacy-addresses" /></t>
</list>
</t>
<t>DHCPv6-based <xref target="RFC3315"/></t>
<t>Specified by transition/co-existence technologies
<list style='symbols'>
<t>IPv4 address and port <xref target="RFC4380" /></t>
</list>
</t>
</list></t>
<t>Deriving the IID from a globally unique IEEE identifier <xref target="RFC2462" /> was one of the earliest mechanisms developed. A number of privacy and security issues related to the interface IDs derived from IEEE identifiers were discovered after their standardization, and many of the mechanisms developed later aimed to mitigate some or all of these weaknesses. This document identifies four types of threats against IEEE-identifier-based IIDs, and discusses how other existing techniques for generating IIDs do or do not mitigate those threats. The discussion in this document is limited to global addresses and does not address link-local addresses. [Do we need to say something about unique-local being in or out of scope?]</t>
</section>
<section title="Terminology">
<t>This section clarifies the terminology used throughout this document.</t>
<t>
<list style="hanging">
<t hangText="Public address:">
<vspace blankLines="0" />An address that has been published in a directory or other public location, such as the DNS, a SIP proxy, an application-specific DHT, or a publicly available URI. A host's public addresses are intended to be discoverable by third parties.</t>
<t hangText="Stable address:">
<vspace blankLines="0" />An address that does not vary over time within the same network. Note that <xref target="RFC4941" /> refers to these as "public" addresses, but "stable" is used here for reasons explained in <xref target="properties" />.</t>
<t hangText="Temporary address:">
<vspace blankLines="0" />An address that varies over time within the same network.</t>
<t hangText="Constant IID:">
<vspace blankLines="0" />An IPv6 Interface Identifier that is globally stable. That is, the Interface ID will remain constant even if the node moves from one network to another.</t>
<t hangText="Stable IID:">
<vspace blankLines="0" />An IPv6 Interface Identifier that is stable within some specified context. For example, an Interface ID can be globally stable (constant), or could be stable per network (meaning that the Interface ID will remain unchanged as long as a the node stays on the same network, but may change when the node moves from one network to another).</t>
<t hangText="Temporary IID:">
<vspace blankLines="0" />An IPv6 Interface Identifier that varies over time.</t>
</list>
</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119" />. These words take their normative meanings only when they
are presented in ALL UPPERCASE.</t>
</section>
<!-- ====================================================================== -->
<section anchor="threats" title="Weaknesses in IEEE-identifier-based IIDs">
<t>There are a number of privacy and security implications that exist for hosts that use IEEE-identifier-based IIDs. This section discusses four generic attack types: correlation of activities over time, location tracking, address scanning, and device-specific vulnerability exploitation. The first three of these rely on the attacker first gaining knowledge of the target host's IID. This can be achieved by a number of different attackers: the operator of a server to which the host connects, such as a web server or a peer-to-peer server; an entity that connects to the same network as the target (such as a conference network or any public network); or an entity that is on-path to the destinations with which the host communicates,
such as a network operator.</t>
<section anchor="correlation" title="Correlation of activities over time">
<t>As with other identifiers, an IPv6 address can be used to correlate the activities of a host for at least as long as the lifetime of the address. The correlation made possible by IEEE-identifier-based IIDs is of particular concern because MAC addresses are much more permanent than, say, DHCP
leases. MAC addresses tend to last roughly the lifetime of a device's
network interface, allowing correlation on the order of years, compared
to days for DHCP.</t>
<t>As <xref target="RFC4941" /> explains,
<list style="hanging">
<t>
"[t]he use of a non-changing interface identifier to form addresses is a
specific instance of the more general case where a constant identifier
is reused over an extended period of time and in multiple independent
activities. Anytime the same identifier is used in multiple contexts,
it becomes possible for that identifier to be used to correlate
seemingly unrelated activity. ... The use of a constant
identifier within an address is of special concern because addresses
are a fundamental requirement of communication and cannot easily be
hidden from eavesdroppers and other parties. Even when higher layers
encrypt their payloads, addresses in packet headers appear in the
clear."
</t>
</list>
</t>
<t>IP addresses are just one example of information that can be used to correlate activities over time. DNS names, cookies <xref target="RFC6265" />, browser fingerprints <xref target="Panopticlick" />, and application-layer usernames can all be used to link a host's activities together. Although IEEE-identifier-based IIDs are likely to last at least as long or longer than these other identifiers, IIDs generated in other ways may have shorter or longer lifetimes than these identifiers depending on how they are generated. Therefore, the extent to which a host's activities can be correlated depends on whether the host uses multiple identifiers together and the lifetimes of all of those identifiers. Frequently refreshing an IPv6 address may not mitigate correlation if an attacker has access to other longer lived identifiers for a particular host. This is an important caveat to keep in mind throughout the discussion of correlation in this document. For further discussion of correlation, see Section 5.2.1 of <xref target="RFC6973" />.</t>
<t>As noted in <xref target="RFC4941" />, in some cases correlation is just as feasible for a host using an IPv4 address as for a host using an IEEE identifier to generate its IID in its IPv6 address. Hosts that use static IPv4 addressing or who are consistently allocated the same address via DHCPv4 can be tracked as described above. However, the widespread use of both NAT and DHCPv4 implementations that assign the same host a different address upon lease expiration mitigates this threat in the IPv4 case as compared to the IEEE identifier case in IPv6.</t>
</section>
<section anchor="location" title="Location tracking">
<t>Because the IPv6 address structure is divided between a topological portion and an interface identifier portion, an interface identifier that remains constant when a host connects to different networks (as an IEEE-identifier-based IID does) provides a way for observers to track the movements of that host. In a passive attack on a mobile host, a server that receives connections from the same host over time would be able to determine the host's movements as its prefix changes.</t>
<t>Active attacks are also possible. An attacker that first learns the host's interface identifier by being connected to the same network segment, running a server that the host connects to, or being on-path to the host's communications could subsequently probe other networks for the
presence of the same interface identifier by sending a probe packet
(ICMPv6 Echo Request, or any other probe packet). Even if the host
does not respond, the first hop router will usually respond with an
ICMP Address Unreachable when the host is not present, and be silent
when the host is present.
</t>
<t>Location tracking based on IP address is generally not possible in IPv4 since hosts get assigned wholly new addresses when they change networks.</t>
</section>
<section anchor="address-scanning" title="Address scanning">
<t>The structure of IEEE-based identifiers used for address generation can be leveraged by an attacker to reduce the target search space <xref target="I-D.ietf-opsec-ipv6-host-scanning"/>. The 24-bit Organizationally Unique Identifier (OUI) of MAC addresses, together with the fixed value (0xff, 0xfe) used to form a Modified EUI-64 Interface Identifier, greatly help to reduce the search space, making it easier for an attacker to scan for individual addresses using widely-known
popular OUIs. This erases much of the protection against address scanning that the larger IPv6 address space was supposed to provide as compared to IPv4.</t>
</section>
<section anchor="device-specific" title="Device-specific vulnerability exploitation">
<t>IPv6 addresses that embed IEEE identifiers leak information about the device (Network Interface Card vendor, or even Operating System
and/or software type), which could be leveraged by an attacker with
knowledge of device/software-specific vulnerabilities to quickly find possible targets. Attackers can exploit vulnerabilities in hosts whose IIDs they have previously obtained, or scan an address space to find potential targets.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="properties" title="Privacy and security properties of address generation mechanisms">
<t>Analysis of the extent to which a particular host is protected against the threats described in <xref target="threats" /> depends on how each of a host's addresses is generated and used. In some scenarios, a host configures a single global address and uses it for all communications. In other scenarios, a host configures multiple addresses using different mechanisms and may use any or all of them.</t>
<t><xref target="RFC3041" /> (later obsoleted by <xref target="RFC4941" />) sought to address some of the problems described in <xref target="threats" /> by defining "temporary addresses" for outbound connections.
Temporary addresses are meant to supplement the other addresses that a
device might use, not to replace them. They use IIDs that are randomly generated and change daily by default. The idea was for temporary addresses to be
used for outgoing connections (e.g., web browsing) while maintaining the ability to use
a stable address when more address stability is desired (e.g., in
DNS advertisements).</t>
<t><xref target="RFC3484" /> originally specified that stable addresses be used for outbound
connections unless an application explicitly prefers temporary
addresses. The default preference for stable addresses was established
to avoid applications potentially failing due to the short lifetime of
temporary addresses or the possibility of a reverse look-up failure or
error. However, <xref target="RFC3484" /> allowed that "implementations for which
privacy considerations outweigh these application compatibility
concerns MAY reverse the sense of this rule" and instead prefer by default temporary addresses rather than stable addresses. Indeed most implementations (notably including Windows) chose to default to temporary
addresses for outbound connections since privacy was considered more
important (and few applications supported IPv6 at the time, so application
compatibility concerns were minimal). <xref target="RFC6724" /> then obsoleted <xref target="RFC3484" />
and changed the default to match what implementations actually did.
</t>
<t>The envisioned relationship in <xref target="RFC3484" /> between stability of an address and its use in "public" can be misleading when conducting privacy analysis. The stability of an address and the extent to which it is linkable to some other public identifier are independent of one another. For example, there is nothing that prevents a host from publishing a temporary address in a public place, such as the DNS. Publishing both a stable address and a temporary address in the DNS or elsewhere where they can be linked together by a public identifier allows the host's activities when using either address to be correlated together.</t>
<t>Moreover, because temporary addresses were designed to supplement other addresses generated by a host, the host may still configure a more stable address even if it only ever intentionally uses temporary addresses (as source addresses) for communication to off-link destinations. An attacker can probe for the stable address even if it is never used as such a source address or advertised (e.g., in DNS or SIP) outside the link.</t>
<t>This section compares the privacy and security properties of a variety of IID generation mechanisms and their possible usage scenarios, including scenarios in which a single mechanism is used to generate all of a host's IIDs and those in which temporary addresses are used together with addresses generated using a different IID generation mechanism. The analysis of the exposure of each IID type to correlation assumes that IPv6 prefixes are shared by a reasonably large number of nodes. As <xref target="RFC4941" /> notes, if a very small number of nodes (say, only one) use a particular prefix for an extended period of time, the prefix itself can be used to correlate the host's activities regardless of how the IID is generated. For example, <xref target="RFC3314" /> recommends that prefixes be uniquely assigned to mobile handsets where IPv6 is used within GPRS. In cases where this advice is followed and prefixes persist for extended periods of time (or get reassigned to the same handsets whenever those handsets reconnect to the same network router), hosts' activities could be correlatable for longer periods than the analysis below would suggest.</t>
<t>The table below provides a summary of the whole analysis.</t>
<texttable anchor="table" title="Privacy and security properties of IID generation mechanisms">
<ttcol align='left'>Mechanism(s)</ttcol>
<ttcol align='left'>Correlation</ttcol>
<ttcol align='left'>Location tracking</ttcol>
<ttcol align='left'>Address scanning</ttcol>
<ttcol align='left'>Device exploits</ttcol>
<c>IEEE identifier</c>
<c>For device lifetime</c>
<c>For device lifetime</c>
<c>Possible</c>
<c>Possible</c>
<c>Static manual</c>
<c>For address lifetime</c>
<c>For address lifetime</c>
<c>Depends on generation mechanism</c>
<c>Depends on generation mechanism</c>
<c>Constant, semantically opaque</c>
<c>For address lifetime</c>
<c>For address lifetime</c>
<c>No</c>
<c>No</c>
<c>CGA</c>
<c>For lifetime of (public key + modifier block)</c>
<c>No</c>
<c>No</c>
<c>No</c>
<c>Stable, semantically opaque</c>
<c>Within single network</c>
<c>No</c>
<c>No</c>
<c>No</c>
<c>Temporary</c>
<c>For temp address lifetime</c>
<c>No</c>
<c>No</c>
<c>No</c>
<c>DHCPv6</c>
<c>For lease lifetime</c>
<c>No</c>
<c>Depends on generation mechanism</c>
<c>No</c>
</texttable>
<section anchor="IEEE" title="IEEE-identifier-based IIDs">
<t>As discussed in <xref target="threats" />, addresses that use IIDs based on IEEE identifiers are vulnerable to all four threats. They allow correlation and location tracking for the lifetime of the device since IEEE identifiers last that long and their structure makes address scanning and device exploits possible.</t>
</section>
<section anchor="manual" title="Static, manually configured IIDs">
<t>Because static, manually configured IIDs are stable, both correlation and location tracking are possible for the life of the address.</t>
<t>The extent to which location tracking can be successfully performed depends, to a some extent, on the uniqueness of the employed Interface ID. For example, one would expect "low byte" Interface IDs to be more widely reused than, for example, Interface IDs where the whole 64-bits follow some pattern that is unique to a specific organization. Widely reused Interface IDs will typically lead to false positives when performing location tracking.</t>
<t>
Whether manually configured addresses are vulnerable to address scanning and device exploits depends on the specifics of how the IIDs are generated.</t>
</section>
<section anchor="random" title="Constant, semantically opaque IIDs">
<t>Although a mechanism to generate a constant, semantically opaque IID has not been standardized, it has been in wide use for many years on at least one platform (Windows). Windows uses the <xref target="RFC4941" /> random generation mechanism in lieu of generating an IEEE-identifier-based IID. This mitigates the device-specific exploitation and address scanning attacks, but still allows correlation and location tracking because the IID is constant across networks and time.</t>
</section>
<section anchor="CGA" title="Cryptographically generated IIDs">
<t>Cryptographically generated addresses (CGAs) <xref target="RFC3972" /> bind a hash of the host's public key to an IPv6 address in the SEcure Neighbor
Discovery (SEND) <xref target="RFC3971" /> protocol. CGAs may be regenerated for each subnet prefix, but this is not required given that they are computationally expensive to generate. A host using a CGA can be correlated for as long as the lifetime of the combination of the public key and the chosen modifier block, since it is possible to rotate modifier blocks without generating new public keys. Because the cryptographic hash of the host's public key uses the subnet prefix as an input, even if the host does not generate a new public key or modifier block when it moves to a different network, its location cannot be tracked via the IID. CGAs do not allow device-specific exploitation or address scanning attacks.</t>
</section>
<section anchor="random-per-network" title="Stable, semantically opaque IIDs">
<t><xref target="I-D.ietf-6man-stable-privacy-addresses" /> specifies a mechanism that generates a unique random IID for each network. A host that stays connected to the same network could therefore be tracked at length, whereas a mobile host's activities could only be correlated for the duration of each network connection. Location tracking is not possible with these addresses. They also do not allow device-specific exploitation or address scanning attacks.</t>
</section>
<section anchor="temporary" title="Temporary IIDs">
<t>A host that uses only a temporary address mitigates all four threats. Its activities may only be correlated for the lifetime a single temporary address.</t>
<t>A host that configures both an IEEE-identifier-based IID and temporary addresses makes the host vulnerable to the same attacks as if temporary addresses were not in use, although the viability of some of them depends on how the host uses each address. An attacker can correlate all of the host's activities for which it uses its IEEE-identifier-based IID. Once an attacker has obtained the IEEE-identifier-based IID, location tracking becomes possible on other networks even if the host only makes use of temporary addresses on those other networks; the attacker can actively probe the other networks for the presence of the IEEE-identifier-based IID. Device-specific vulnerabilities can still be exploited. Address scanning is also still possible because the IEEE-identifier-based address can be probed.</t>
<t>If the host instead generates a constant, semantically opaque IID to use in a stable address for server-like connections together with temporary addresses for outbound connections (as is the default in Windows), it sees some improvements over the previous scenario. The address scanning and device-specific exploitation attacks are no longer possible because the OUI is no longer embedded in any of the host's addresses. However, correlation of some activities across time and location tracking are both still possible because the semantically opaque IID is constant. And once an attacker has obtained the host's semantically opaque IID, location tracking is possible on any network by probing for that IID, even if the host only uses temporary addresses on those networks. However, if the host generates but never uses a constant, semantically opaque IID, it mitigates all four threats.</t>
<t>When used together with temporary addresses, the stable, semantically opaque IID generation mechanism <xref target="I-D.ietf-6man-stable-privacy-addresses" /> improves upon the previous scenario by limiting the potential for correlation to the lifetime of the stable address (which may still be lengthy for hosts that are not mobile) and by eliminating the possibility for location tracking (since a different IID is generated for each subnet prefix). As in the previous scenario, a host that configures but does not use a stable, semantically opaque address mitigates all four threats.</t>
</section>
<section anchor="DHCPv6" title="DHCPv6 generation of IIDs">
<t>The security/privacy implications of DHCPv6-based addresses will
typically depend on the specific DHCPv6 server software being
employed. We note that recent releases of most popular DHCPv6 server
software typically lease random addresses with a similar lease time as
that of IPv4. Thus, these addresses can be considered to be "stable,
semantically opaque."</t>
<t>On the other hand, some DHCPv6 software leases sequential addresses
(typically low-byte addresses). These addresses can be considered to be
stable addresses. The drawback of this address generation scheme compared to "stable, semantically opaque" addresses is that, since they
follow specific patterns, they enable IPv6 address scans.</t>
</section>
<section anchor="transition" title="Transition/co-existence technologies">
<t>Addresses specified based on transition/co-existence technologies that embed an IPv4 address within an IPv6 address are not included in <xref target="table" /> because their privacy and security properties are inherited from the embedded address. For example, Teredo <xref target="RFC4380" /> specifies a means to generate an IPv6 address from
the underlying IPv4 address and port, leaving many other bits set to
zero. This makes it relatively easy for an attacker to scan for IPv6
addresses by guessing the Teredo client's IPv4 address and port (which
for many NATs is not randomized). For this reason, popular implementations (e.g., Windows), began
deviating from the standard by including 12 random bits in place of
zero bits. This modification was later standardized in <xref target="RFC5991" />.</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Miscellaneous Issues with IPv6 addressing">
<!-- I'd remove the following section - for instance, we're targetting Informational, rather than Std Track or BCP -->
<section anchor="geo" title="Geographic Location">
<t>Since IPv6 subnets have unique prefixes, they reveal some information
about the location of the subnet, just as IPv4 addresses do. Hiding this
information is one motivation for using NAT in IPv6 (see RFC 5902
section 2.4).</t>
</section>
<section title="Network Operation">
<t>
It is generally agreed that IPv6 addresses that vary over time in a specific network tend to increase the complexity of event logging, trouble-shooting, enforcement of access controls and quality of service, etc. As a result, some organizations disable the use of temporary addresses <xref target="RFC4941"/> even at the expense of reduced privacy <xref target="Broersma"/>.</t>
</section>
<section anchor="guidance" title="Compliance">
<t>Major IPv6 compliance testing suites required (and still require)
implementations to support MAC-derived suffixes in order to be
approved as compliant. Implementations that fail to support
MAC-derived suffixes are therefore largely not eligible to receive the
benefits of compliance certification (e.g., use of the IPv6 logo,
eligibility for government contracts, etc.). This document recommends
that these be relaxed to allow other forms of address generation that
are more amenable to privacy.
</t>
</section>
<section anchor="ipr" title="Intellectual Property Rights (IPRs)">
<t>Some IPv6 addressing techniques might be covered by Intellectual Property rights, which might limit their implementation in different Operating Systems. <xref target="CGA-IPR"/> and <xref target="KAME-CGA"/> discuss the IPRs on CGAs.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="SecurityConsiderations" title="Security Considerations">
<t>This whole document concerns the privacy and security properties of different IPv6 address generation mechanisms.</t>
</section>
<!-- ====================================================================== -->
<section anchor="iana" title="IANA Considerations">
<t>
This document does not require actions by IANA. </t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgements">
<t>The authors would like to thank Bernard Aboba, Rich Draves, and James Woodyatt.</t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Informative References">
&RFC1972;
&RFC2119;
&RFC2462;
&RFC2464;
&RFC3041;
&RFC3314;
&RFC3315;
&RFC3484;
&RFC3971;
&RFC3972;
&RFC4380;
&RFC4941;
&RFC5991;
&RFC6265;
&RFC6724;
&RFC6973;
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6man-stable-privacy-addresses.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsec-ipv6-host-scanning.xml"?>
<reference anchor="Microsoft">
<front>
<title>IPv6 interface identifiers</title>
<author>
<organization>Microsoft</organization>
</author>
<date year="2013"/>
</front>
<format type='HTML'
target='http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true' />
</reference>
<reference anchor="Panopticlick">
<front>
<title>Panopticlick</title>
<author>
<organization>Electronic Frontier Foundation</organization>
</author>
<date year="2011" />
</front>
<format target="http://panopticlick.eff.org" type="HTML" />
</reference>
<reference anchor="CGA-IPR">
<front>
<title>Intellectual Property Rights on RFC 3972</title>
<author>
<organization>IETF</organization>
</author>
<date year="2005"/>
</front>
<format type='HTML'
target='https://datatracker.ietf.org/ipr/search/?option=rfc_search&rfc_search=3972' />
</reference>
<reference anchor="KAME-CGA">
<front>
<title>The KAME IPR policy and concerns of some technologies which have IPR claims</title>
<author>
<organization>KAME</organization>
</author>
<date year="2005"/>
</front>
<format type='TXT'
target='http://www.kame.net/newsletter/20040525/' />
</reference>
<reference anchor="Broersma" target="http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf">
<front>
<title abbrev="IPv6 Everywhere">IPv6 Everywhere: Living with a Fully IPv6-enabled environment</title>
<author
fullname="Ron Broersma"
initials="R."
surname="Broersma">
<organization abbrev="DREN">Defense Research and Engineering Network</organization>
</author>
<date month="October" year="2010"/>
</front>
<seriesInfo name="" value="Australian IPv6 Summit 2010, Melbourne, VIC Australia, October 2010"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 23:16:36 |