Internet DRAFT - draft-daveor-slaac-privacy-logging
draft-daveor-slaac-privacy-logging
Internet Engineering Task Force D. O'Reilly
Internet-Draft May 27, 2018
Intended status: Informational
Expires: November 28, 2018
A Model for Storing IPv6 Stateless Address Autoconfiguration Crime
Attribution Records in a Privacy Sensitive Way
draft-daveor-slaac-privacy-logging-00
Abstract
The need for individual right to privacy and the need for law
enforcement to be able to effectively investigate crime are sometimes
portrayed as being irreconcilably in direct conflict with each other.
Both needs are legitimate and ignoring the challenges presented by
areas of conflict will not make the problem go away.
The document presents a conceptual model that allows for both sets of
requirements to be met simultaneously. The reason for this
publication is to show that, with some creative thinking, it is
possible to identify win-win solutions that simultaneously achieve
both privacy and law enforcement goals.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 28, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
O'Reilly Expires November 28, 2018 [Page 1]
Internet-Draft SLAAC Privacy Logging May 2018
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. SLAAC: Stateless Address Autoconfiguration . . . . . . . 3
1.1.1. Stable Address Autoconfiguration . . . . . . . . . . 4
1.1.2. Temporary Address Autoconfiguration . . . . . . . . . 5
1.1.3. Crime Attribution Characteristics . . . . . . . . . . 7
1.1.3.1. Stateless Address Autoconfiguration . . . . . . . 7
1.1.3.2. SLAAC with stable interface identifiers . . . . . 8
1.1.3.3. SLAAC with temporary interface identifiers . . . 8
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Record Generation . . . . . . . . . . . . . . . . . . . . 9
3.3. Record Transmission and Storage . . . . . . . . . . . . . 10
3.4. Record Querying . . . . . . . . . . . . . . . . . . . . . 11
4. Proof of Concept . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 12
6.2. Injection of False Records . . . . . . . . . . . . . . . 13
6.3. Retention Period of Records . . . . . . . . . . . . . . . 13
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Normative References . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
IPv6 addresses are assigned to organisations in blocks that are much
larger than the size of the blocks in which IPv4 addresses are
assigned, with common IPv6 prefix sizes being /48, /56 and /64
[RFC6177], [RIPE_699]. Current regulatory models typically oblige
ISPs to keep records to facilitate identification of their
subscribers, and in the case of IPv6 this will mean recording the
prefix(es) have been assigned to each customer.
From the perspective of crime attribution, therefore, when a specific
IP address is suspected to be associated with criminal activity,
records will most likely available from an ISP to identify the
organisation to which the prefix has been assigned. The question
O'Reilly Expires November 28, 2018 [Page 2]
Internet-Draft SLAAC Privacy Logging May 2018
then arises how an organisation approached by law enforcement
authorities, particularly a large organisation, would be able to
ascertain which host/endpoint within their network was using a
particular IP address at a particular time.
This is not a new problem, with many difficulties of crime
attribution already present in the IPv4 Internet. Nevertheless, it
is worthwhile to consider the crime attribution characteristics of
IPv6 in anticipation of wider deployment of this technology in the
coming years.
IPv6 provides several mechanisms through which hosts can be assigned
an IP address. [RFC7721] provides a list of these. Briefly they can
be summarised as:
o Manually configured addresses
o DHCPv6 assigned addresses
o Stateless Address Autoconfiguration (SLAAC)
o Addresses derived from an IPv4 address (transitional)
When approached by a law enforcement agency to identify the host/
endpoint that was using a particular IP address at a particular time,
the organisation's ability to deliver this information will depend on
how IPv6 addresses are being assigned to endpoints within their
network.
1.1. SLAAC: Stateless Address Autoconfiguration
IPv6 Stateless Address Autoconfiguration (SLAAC) describes the
process used by a host in deciding how to auto configure its
interfaces in IPv6[RFC4862]. This includes generating a link-local
address, generating global addresses via stateless address
autoconfiguration and then using duplicate address detection to
verify the uniqueness of the addresses on the link. SLAAC requires
no manual configuration of hosts, minimal (if any) configuration of
routers, and no additional servers.
Routers advertise prefixes that identify the subnet(s) associated
with a link and hosts generate an interface identifier that uniquely
identifies an interface on a subnet. An address is formed by
combining these two. In the absence of a router, hosts generate only
link-local addresses. Autoconfiguration is only possible on
multicast-capable links.
O'Reilly Expires November 28, 2018 [Page 3]
Internet-Draft SLAAC Privacy Logging May 2018
The process begins by generating a link-local address for the
interface. This is achieved by appending the interface identifier to
the well-known link-local prefix. At this point, the address is
considered "tentative" because it might be in use by another host on
the network. The host verifies the uniqueness of the address by
sending a Neighbour Solicitation message containing the tentative
address. If the address is already in use, the node that is using
that address will send back a Neighbour Advertisement message. If
the address is not unique, auto configuration stops and manual
configuration is required or an alternative interface identifier can
be used, if one is configured.
Once it has been established that the link-local address is unique,
it is assigned to the interface. Next, the host listens for a Router
Advertisement message or, if the host does not want to wait, it can
send a Router Solicitation message to the all-routers multicast
group.
Router Advertisement messages contain zero or more prefix information
options that contain information that can be used to generate global
addresses. Hosts can use stateless address autoconfiguration and
DHCPv6 simultaneously if they want. If the Router Advertisement
indicates that the prefixes can be used for autoconfiguration (by
setting the "autonomous address-configuration flag" in the Prefix
Information option field) it will also include a subnet prefix and
lifetime values, indicating how long addresses created from this
prefix will remain preferred and valid. Hosts process all Router
Advertisements that are received periodically, adding to and
refreshing the information received in previous advertisements.
Crucial to the crime attribution properties of SLAAC is the selection
of interface identifier. Various algorithms exist for the generation
of interface identifiers, depending on whether the interface
identifier is intended to be stable (long-lived) or temporary. The
following two sub-sections describe stable and temporary interface
identifier generation algorithms.
1.1.1. Stable Address Autoconfiguration
Originally, various standards specified that the interface identifier
should be generated from the link-layer address of the interface.
For example [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497],
[RFC2590], [RFC3164], [RFC3527], [RFC4338], [RFC4391], [RFC5072],
[RFC5121]. This is used in cases where a stable IPv6 address is
being generated.
[RFC8064] changes the recommended default interface identifier
generation scheme when SLAAC is in use to generate stable IPv6
O'Reilly Expires November 28, 2018 [Page 4]
Internet-Draft SLAAC Privacy Logging May 2018
addresses. It recommends against embedding stable link-layer
addresses in IPv6 interface identifiers, recommending instead the use
of a semantically opaque value as defined in [RFC7217] over all other
alternatives. [RFC8064] also highlights some reasons why a stable
IPv6 address would be desirable. For example, network management,
event logging, enforcement of access control, provision of quality of
service or for server or router interfaces. Similarly, they allow
long-lived TCP connections. However, the document does not make
recommendations about WHEN stable addresses should be used and when
temporary addresses should be used.
[RFC7271] describes a method where an IPv6 address can be configured
in such a way that it is stable within each subnet but the interface
identifier changes when the host moves from one network to another.
In general terms, the approach is to pass the following values to a
cryptographic hash function (such as SHA1 or SHA256):
o The network prefix
o The network interface id
o The network id (subnet, SSID or similar) - optional parameter
o A duplicate address detection counter - incremented in case of a
duplicate address being generated
o A secret key (128 bits long at least)
The interface identifier is generated by taking as many bits,
starting at the least significant, as required. The result is an
opaque bit stream that can be used as the interface id.
1.1.2. Temporary Address Autoconfiguration
[RFC4941] describes a system by which interface identifiers generated
from an IEEE identifier (EUI-64) can be changed over time, even in
cases where the interface contains an embedded IEEE identifier.
These are referred to as temporary addresses.
The reason behind development of this technique is that the use of a
globally unique, non-changing, interface identifier means that the
activity of a specific interface can be tracked even if the network
prefix changes. The use of a fixed identifier in multiple contexts
allows correlation of seemingly unrelated activity using the
identifier. Contrast this with IPv4 addresses, where if a person
changes to a different network their entire IP address will change.
The goals of the temporary address generation procedure are that:
O'Reilly Expires November 28, 2018 [Page 5]
Internet-Draft SLAAC Privacy Logging May 2018
o Temporary address generation does not result in any changes to the
basic behaviour of addresses generated via SLAAC.
o The temporary address generation algorithm creates additional
addresses based on a random interface identifier for the purpose
of initiating outgoing sessions. These temporary addresses would
be used for a short period of time (hours to days) and would then
be deprecated.
o The algorithm produces a sequence of temporary global scope
addresses from the sequence of interface identifiers that appear
to be random in the sense that it is difficult for an outside
observer to predict a future address (or identifier) based on the
current one, or to determine a previous address (or identifier)
knowing only the current one.
o By default, the algorithm generates a set of addresses from the
same interface identifier, one for each prefix for which a global
address has been generated via SLAAC. Using the same interface
identifier to generate a set of temporary addresses reduces the
number of IP multicast groups that a host must join.
o A node highly concerned about privacy may use different
identifiers for different prefixes, resulting in a set of global
addresses that cannot be easily tied to each other.
To prevent the generation of predictable values, the algorithm must
contain an unpredictable component. The algorithm assumes that each
interface maintains an associated randomised interface identifier.
When temporary addresses are generated, the current value of the
interface identifier is used. The algorithm also assumes that for a
given temporary address, the implementation can determine the prefix
from which it was generated.
Two approaches to generate random interface identifiers are presented
in [RFC4941], depending on whether stable storage is present.
When stable storage is present, it is assumed that a 64-bit history
value is available and can be used. This value is generated as
described below. The first time the system boots, a random value is
selected.
1. Take the history value and append it to the interface identifier
generated as described in [RFC4291].
2. Compute the MD5 of the resulting value
O'Reilly Expires November 28, 2018 [Page 6]
Internet-Draft SLAAC Privacy Logging May 2018
3. Take the leftmost 64 bits and set bit 6 to zero. (This creates
an interface identifier with the universal/local bit indicating
local significance only)
4. Compare the generated identifier against a list of reserved
identifiers and to those already assigned to an address on the
local device. If an unacceptable value has been generated, start
again at step 1.
5. Save the generated identifier.
6. Take the rightmost 64 bits and save them to state storage as the
history value for the next iteration of the algorithm.
When stable storage is not present, no history value will be
available. Therefore, the initial history value should be generated
at random. Algorithms other than MD5 can be used to compute the
temporary address if desired.
Other approaches such as cryptographically generated addresses (CGA)
can be used to generate random interface identifiers based on the
public key of the node [RFC3972]. The goal of CGAs is to prove
ownership of an address and prevent spoofing and stealing of IPv6
addresses. The CGA process may not be suitable for privacy addresses
because (a) it requires nodes to have a public key, meaning the node
can be identified by the key and (b) it is computationally intensive,
discouraging frequent regeneration.
Devices implementing this specification must provide a way for end
users to explicitly enable or disable the use of temporary addresses.
Also, sites might wish to disable it, so implementations should
provide a way for trusted system administrators to enable or disable
the use of temporary addresses. Implementations should also provide
a way to enable and disable generation of temporary addresses for
specific prefix subranges.
1.1.3. Crime Attribution Characteristics
1.1.3.1. Stateless Address Autoconfiguration
IPv6 addresses are assigned to organisations in blocks much larger
than the size of the blocks in which IPv4 addresses are assigned.
The question arises about how an organisation approached by law
enforcement authorities, particularly a large organisation, will be
able to ascertain which host/endpoint within their organisation was
using a particular IP address at a particular time when addresses
have been assigned using SLAAC.
O'Reilly Expires November 28, 2018 [Page 7]
Internet-Draft SLAAC Privacy Logging May 2018
From the crime attribution perspective, both the recommended stable
and temporary address generation algorithms pseudo-randomly select
addresses from the space of available addresses. When SLAAC is being
used, the hosts auto-configure the IP addresses of their interfaces,
meaning there is no organisational record of the IP addresses that
have been selected by particular hosts at particular points in time.
1.1.3.2. SLAAC with stable interface identifiers
From a crime attribution point of view, the use of a stable interface
identifier (whether generated for a link-local address or otherwise)
will provide some measure of assurance that it will be possible to
identify a specific host/interface based on the IPv6 address. While
it may not be possible for a network administrator to calculate the
interface identifier (and therefore the IPv6 address) that will be
used by a specific interface, due to the presence of a secret key,
with some effort it should be possible for a network operator to
determine which host/endpoint, or at least a relatively small subset
of hosts/endpoints, is responsible for traffic arising from a
particular IPv6 address.
Due to the relatively long-term use of a particular address by an
interface, it is at least possible that an organisation might be able
to use traffic flow analysis or other similar network monitoring
techniques to identify the endpoint using the address. This assumes
that the IPv6 address is still active and generating traffic. It
will also, of course, only identify the endpoint using the address at
the time of the traffic flow analysis and not at the time of the
alleged criminal activity that is under investigation.
1.1.3.3. SLAAC with temporary interface identifiers
The problem of crime attribution is exacerbated in the case of
temporary interface identifier generation due to the fact that the
generated addresses are the endpoint's preferred IPv6 address, by
default, for a period of one day [RFC4941].
It is difficult to see how the activity of IPv6 addresses generated
using temporary interface identifiers could be attributed to any
host/endpoint. The interface identifier generation algorithm has a
cryptographic component, meaning that the addresses will appear to be
pseudo-randomly selected from the range of available addresses.
Even presuming that the host/endpoint is still active and generating
traffic there is no apparent way to associate the activity of the
host/endpoint's current address with the address in use at the time
of the alleged criminal activity.
O'Reilly Expires November 28, 2018 [Page 8]
Internet-Draft SLAAC Privacy Logging May 2018
This attribution problem is "by design", arising from the expected
behaviour of SLAAC with temporary interface identifiers. It
therefore seems that the crime attribution challenges that will arise
from the use of this technology have not been given due
consideration. The use of this technology will likely become a
significant crime attribution challenge in future.
2. Scope
This document presents a record-retention model whereby it is
possible for an organisation, if required to do so as part of a
criminal investigation, to answer the question "Who was using IP
address A at a particular point in time?" without being able to
answer any more broadly scoped questions, such as "What were all of
the IP addresses used by a particular person?"
3. Model
3.1. Assumptions
The model described here makes the following assumption:
o The endpoint/interface for which the IPv6 address is being
generated has a meaningful, unique identifying characteristic.
Whether that is the layer two address of the interface or some
other organisational characteristic is unimportant for the purpose
of the model.
3.2. Record Generation
The host generates a temporary IPv6 address using any of the
techniques described above, but most likely the technique described
in [RFC4941]. Having completed the duplicate address detection phase
of SLAAC, but before beginning to use the IP address for
communication, the host creates a structure of the following form:
typedef struct {
const char *LOG_ENTRY_TAG="__LOG_ENTRY_TAG__";
unsigned char *ip_address;
unsigned int identifying_characteristic_length;
unsigned char *identifying_characteristic;
unsigned int client_generation_time;
unsigned int client_preferred_time;
unsigned int client_valid_time;
} log_entry;
The fields in the structure are all mandatory, and populated as
follows:
O'Reilly Expires November 28, 2018 [Page 9]
Internet-Draft SLAAC Privacy Logging May 2018
o LOG_ENTRY_TAG has the fixed, constant value "__LOG_ENTRY_TAG__"
o ip_address contains the 16 byte IPv6 address
o identifying_characteristic_length contains the byte length of the
identifying_characteristic field
o identifying_characteristic is a variable length byte string,
organisationally interpreted, to represent the identifying
characteristic of the host generating the IPv6 address
o client_generation_time contains the time, in seconds since the
unix epoch, as recorded by the client creating the IPv6 address,
at which the address was generated
o client_preferred_time contains the period, in seconds, starting at
client_generation_time for which the client will use this IPv6
address as its preferred address
o client_valid_time contains the period, in seconds, starting at
client_generation_time for which the client will consider this
IPv6 address to be valid
When the structure has been populated, the host encrypts the
structure using AES-128 in CBC mode with the selected IPv6 address
being used as the encryption key.
The record message is now ready for transmission.
3.3. Record Transmission and Storage
The host submits the completed record to a specified multicast
address and port but, when sending the record, sends it using the
unspecified IPv6 address (i.e. "::") as the source IP address.
When records are received by a logging server that is listening to
the specified multicast address, the logging server creates a new log
entry consisting of:
o The time the record was received, ideally calibrated to a global
standard time (e.g. NTP) with the granularity of a second.
o The received encrypted record as a binary blob.
O'Reilly Expires November 28, 2018 [Page 10]
Internet-Draft SLAAC Privacy Logging May 2018
3.4. Record Querying
If and when it becomes necessary to query the recorded entries, the
following (representative) process can be followed:
1. Taking the IP address for which the attribution information is
required, iterate through all recorded log entries and use the IP
address as a decryption key and attempt to decrypt the record.
2. Examine the decrypted data and check whether the first 17 bytes
have the values "__LOG_ENTRY_TAG__".
A. If so:
i This indicates that the log entry has been successfully
decrypted.
ii The IP address contained in the log entry can be verified
against the IP address that was used as a key to confirm
that the log entry contains the correct value.
iii The identifying characteristic can then be read from the
log entry, along with the time at which the host
generated the IP address.
iv The client_preferred_time and client_valid_time fields
can be used to check whether the IPv6 address was valid
and/or preferred by the client at the time of interest.
v The time in the record can be correlated with the time in
the log entry recorded by the server so that any time
differential can be compensated for.
B. If not:
i This indicates that the log entry has not been
successfully decrypted and that the current log entry
pertains to a different IP address.
ii Move on to the next log entry and try again.
As described in the next section, it would be computationally
feasible to use this process on a large number of log entries but, if
necessary, the space of log entries to be searched can be reduced by
selecting a range of log entries based on the time recorded by the
server.
O'Reilly Expires November 28, 2018 [Page 11]
Internet-Draft SLAAC Privacy Logging May 2018
4. Proof of Concept
A proof of concept implementation of the model above has been
developed. Log entries using pseudorandom IPv6 addresses were
generated for a network of 20,000 computers, changing IP address
every day (which is the default specified in [RFC4941]) for two
years. This leads to the generation of 14.6 million log entries.
Code was developed to select a random IP address, known to be
represented in the log entries, and search the entire log for entries
that are successfully decrypted using that IP address. This code was
executed 10,000 times and the following results were noted:
1. On a single CPU PC with an Intel Core i7 running at 2.8GHz it
takes on average 11.34 seconds (standard deviation 0.82 seconds)
to check the entire log.
2. In all 10,000 test cases, only a single log entry was
successfully decrypted - the one representing the attribution
data for the target IP address.
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
6.1. Cryptographic Strength
The strength of the key comes from the length and pseudo-random
nature of the IPv6 address generation mechanism, the very feature
that is desirable from a privacy perspective.
In order to decrypt a specific log entry without knowing the target
IP address, a brute force approach must be adopted. Presuming a
known 64-bit address prefix, means that there is a space of 2^64
possible addresses to search.
Code was also developed to attempt to brute force log entries, and it
was noted that on the same PC used for the testing above (single CPU
PC with an Intel Core i7 running at 2.8GHz) attempting to brute force
a single log entry would be computationally infeasible (approximately
22,313,257 years required). To decrypt the entire log would require
this same amount of time for each individual log entry.
O'Reilly Expires November 28, 2018 [Page 12]
Internet-Draft SLAAC Privacy Logging May 2018
6.2. Injection of False Records
In the model presented here, there is no mechanism to detect
injection of false records. A shared secret cryptographic model
could be developed but in order to maintain the privacy
characteristics of the concept, all authorised endpoints would need
to use the same shared secret otherwise it would be possible to a
rogue log recorder to reduce the range of possible hosts through
correlation of the encryption key.
6.3. Retention Period of Records
The period of time for which logs should be retained is, broadly
speaking, out of scope of this discussion.
Depending on national legislation there will be obligations on
certain types of organisations to retain logs for particular periods
of time. Most other organisations do not have any legal obligation
to retain records of which endpoint was using a specific IP address
at a particular point in time, although these records are often kept
for other reasons such as network security, performance monitoring
and troubleshooting.
7. Conclusion
The model presented here provides a balance between the needs for
individual privacy at the network layer while also providing a
mechanism for recording data that would be required in a criminal
investigation. The balance that has been proposed here is at the
point where it is possible to identify, using this technique, who was
using a specific IP address at a specific point in time without being
able to extract any more information such as all of the people who
were using a particular IP or all of the IP addresses that were used
by a particular endpoint.
8. Normative References
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998,
<https://www.rfc-editor.org/info/rfc2467>.
[RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of
IPv6 Packets over Token Ring Networks", RFC 2470,
DOI 10.17487/RFC2470, December 1998,
<https://www.rfc-editor.org/info/rfc2470>.
O'Reilly Expires November 28, 2018 [Page 13]
Internet-Draft SLAAC Privacy Logging May 2018
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, DOI 10.17487/RFC2491, January 1999,
<https://www.rfc-editor.org/info/rfc2491>.
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999,
<https://www.rfc-editor.org/info/rfc2492>.
[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet
Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999,
<https://www.rfc-editor.org/info/rfc2497>.
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of
IPv6 Packets over Frame Relay Networks Specification",
RFC 2590, DOI 10.17487/RFC2590, May 1999,
<https://www.rfc-editor.org/info/rfc2590>.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
DOI 10.17487/RFC3164, August 2001,
<https://www.rfc-editor.org/info/rfc3164>.
[RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
"Link Selection sub-option for the Relay Agent Information
Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April
2003, <https://www.rfc-editor.org/info/rfc3527>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of
IPv6, IPv4, and Address Resolution Protocol (ARP) Packets
over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338,
January 2006, <https://www.rfc-editor.org/info/rfc4338>.
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over
InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April
2006, <https://www.rfc-editor.org/info/rfc4391>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
O'Reilly Expires November 28, 2018 [Page 14]
Internet-Draft SLAAC Privacy Logging May 2018
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<https://www.rfc-editor.org/info/rfc5072>.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Madanapalli, "Transmission of IPv6 via the IPv6
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121,
DOI 10.17487/RFC5121, February 2008,
<https://www.rfc-editor.org/info/rfc5121>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011,
<https://www.rfc-editor.org/info/rfc6177>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H.,
D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS
Transport Profile (MPLS-TP) Linear Protection to Match the
Operational Expectations of Synchronous Digital Hierarchy,
Optical Transport Network, and Ethernet Transport Network
Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014,
<https://www.rfc-editor.org/info/rfc7271>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[RIPE_699]
RIPE, "IPv6 Address Allocation and Assignment Policy",
2016, <https://www.ripe.net/publications/docs/ripe-699>.
O'Reilly Expires November 28, 2018 [Page 15]
Internet-Draft SLAAC Privacy Logging May 2018
Author's Address
David O'Reilly
Ireland
Email: rfc@daveor.com
O'Reilly Expires November 28, 2018 [Page 16]
