Internet DRAFT - draft-daveor-ipv6-crime-attribution
draft-daveor-ipv6-crime-attribution
Internet Engineering Task Force D. O'Reilly
Internet-Draft April 24, 2018
Intended status: Informational
Expires: October 26, 2018
Analysis of the Crime Attribution Characteristics of Various IPv6
Address Assignment Techniques
draft-daveor-ipv6-crime-attribution-00
Abstract
The migration from IPv4 to IPv6 is intended to fix a large number of
problems with IPv4 that have been identified through many years of
global use, not least of which is the shortage of available IPv4
addresses. One of the challenges with IPv4 that has not, apparently,
been adequately considered is the crime attribution characteristics
of IPv6 technologies.
The challenge of crime attribution on the Internet is an important
one and a careful balance needs to be struck between the needs of law
enforcement, the rights of crime victims and the right to privacy of
the vast majority of Internet users who have no involvement in any
sort of criminality.
The purpose of this document is to consider the crime attribution
characteristics of various IPv6 address assignment techniques.
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 October 26, 2018.
O'Reilly Expires October 26, 2018 [Page 1]
Internet-Draft IPv6 Crime Attribution April 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
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Background on IPv6 Address Architecture . . . . . . . . . 5
2. IPv6 Endpoint Address Assignment . . . . . . . . . . . . . . 7
2.1. Manual IPv6 Address Configuration . . . . . . . . . . . . 7
2.1.1. Crime Attribution Characteristics . . . . . . . . . . 8
2.1.1.1. Locating a host using a manually assigned IPv6
address . . . . . . . . . . . . . . . . . . . . . 8
2.1.1.2. Rogue clients . . . . . . . . . . . . . . . . . . 8
2.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Crime Attribution Characteristics . . . . . . . . . . 9
2.2.1.1. Availability of Attribution Records . . . . . . . 10
2.2.1.2. Rogue clients . . . . . . . . . . . . . . . . . . 10
2.3. SLAAC: Stateless Address Autoconfiguration . . . . . . . 10
2.3.1. Stable Address Autoconfiguration . . . . . . . . . . 11
2.3.2. Temporary Address Autoconfiguration . . . . . . . . . 12
2.3.3. Crime Attribution Characteristics . . . . . . . . . . 14
2.3.3.1. Stateless Address Autoconfiguration . . . . . . . 14
2.3.3.2. SLAAC with stable interface identifiers . . . . . 15
2.3.3.3. SLAAC with temporary interface identifiers . . . 15
2.4. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . 16
2.4.1. Crime Attribution Characteristics . . . . . . . . . . 17
2.4.1.1. Mapping/Translation Technologies . . . . . . . . 17
2.4.1.2. Tunnelling Technologies . . . . . . . . . . . . . 17
2.5. IPv6 Mobility Addresses . . . . . . . . . . . . . . . . . 18
2.5.1. Crime Attribution Characteristics . . . . . . . . . . 20
2.5.1.1. Attribution of the activity of the mobile node
from information available at the home network . 20
2.5.1.2. Attribution of the activity of the mobile node
from information available at the care-of network 21
2.5.1.3. The ephemeral nature of correspondent
O'Reilly Expires October 26, 2018 [Page 2]
Internet-Draft IPv6 Crime Attribution April 2018
routing/route optimisation information . . . . . 21
2.6. IPv6 Address Selection . . . . . . . . . . . . . . . . . 22
2.6.1. Crime Attribution Characteristics . . . . . . . . . . 23
2.7. IPv6 Edge Router Recommendations . . . . . . . . . . . . 23
2.7.1. Crime Attribution Characteristics . . . . . . . . . . 23
2.8. IPv6 Prefix Per Host . . . . . . . . . . . . . . . . . . 23
2.8.1. Crime Attribution Characteristics . . . . . . . . . . 24
2.8.1.1. Usage of endpoint addresses . . . . . . . . . . . 24
2.8.1.2. Frequently changing prefixes . . . . . . . . . . 24
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Informative References . . . . . . . . . . . . . . . . . 25
6.2. Normative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
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
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'Reilly Expires October 26, 2018 [Page 3]
Internet-Draft IPv6 Crime Attribution April 2018
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. This document considers the crime attribution
characteristics of the address assignment methodologies listed above.
The crime attribution characteristics of several related topics are
also considered:
o [RFC6275] describes Mobile IPv6, a protocol that allows nodes to
remain reachable while moving around in the IPv6 Internet. As a
fundamental service in an IPv6 stack, it is expected that Mobile
IPv6 will be deployed in most nodes of the Internet. Through this
technique, a host/endpoint would temporarily use an address from a
different global prefix space.
o It is not uncommon for a host/endpoint to have multiple IPv6
addresses of various scopes and, similarly, for a destination
host/endpoint to also have multiple IPv6 addresses that the source
could select to communicate with. Recommendations have been
published for default algorithms that hosts can use to select both
source and destination addresses from the available options.
[RFC6724]
o Previous work has also published requirements for IPv6 customer
edge routers. [RFC7084]
o For reasons of improved host isolation and enhanced subscriber
management on shared network segments, there are approaches
available for assigning IPv6 prefixes to individual hosts.
[RFC8273], [RFC3314], [RFC7934]
1.1. Scope
This document considers only one scenario, as follows; through some
means of investigation, an IPv6 address is suspected to be associated
with criminal activity. How the IPv6 address has been associated
with criminal activity is beyond the scope of this document - the
starting point of this document is that an IPv6 address has already
been identified (e.g. from logs of a victim or through other
investigative means). What are the challenges arising from the use
O'Reilly Expires October 26, 2018 [Page 4]
Internet-Draft IPv6 Crime Attribution April 2018
of IPv6 in attributing the activity of the suspect address to a
specific endpoint?
Other aspects of the investigative process, including those that
might be sources of evidence, which are out of scope of this
document, include:
o Attribution of criminal activity through identification and
collection of information from upper layer protocol analysis (e.g.
TCP flow analysis, HTTP cookies, usernames or other application-
layer session data).
o Attribution of criminal activity through the identification and
collection of information from non-technical sources (e.g. covert
investigations, crime reports, etc.) that can associate an
individual with the activity of a specific IPv6 address.
o Associating the activity of a host or endpoint with a real-world
human being.
The security considerations associated with each of the technologies
discussed are also out of scope except inasmuch as they influence the
crime attribution characteristics of the technology.
1.2. Background on IPv6 Address Architecture
The IPv6 addressing model is defined in [RFC4291]. This section
provides a brief summary of the salient points of the IPv6 addressing
model, the full detail of which can be found in the RFC.
In the IPv6 addressing model, addresses are assigned to interfaces,
not nodes. There are three types of addresses:
o Unicast addresses identify a single interface.
o Anycast addresses identify a set of interfaces. A packet sent to
an anycast address is delivered to one of the interfaces in the
set. The packet will be sent to the "nearest" interface in the
set, nearness being defined according to the routing protocol's
measure of distance.
o Multicast addresses identify a set of interfaces. A packet sent
to a multicast address is delivered to all of the interfaces in
the set.
There are no broadcast addresses in IPv6, their function being
superseded by multicast addresses.
O'Reilly Expires October 26, 2018 [Page 5]
Internet-Draft IPv6 Crime Attribution April 2018
There are a number of special ranges of IPv6 addresses:
o An IPv6 address consisting of all zeros is the unspecified address
(::/128) and this cannot be assigned to any node.
o An IPv6 address consisting of 127 zeros with the lowest bit being
1 is the loopback address (::1/128).
o Multicast addresses begin with the prefix FF00::/8.
o Link-local unicast addresses begin with the prefix FE80::/10.
Link-local unicast addresses are for use on a single link and will
not be forwarded by routers to other links.
o Site-local unicast addresses begin with the prefix FEC0::/10.
This deprecated prefix was intended for addressing within a site
without the need for a global prefix. New implementations must
treat this prefix as global unicast addresses.
o All other addresses are global unicast addresses. Anycast
addresses are also taken from the global unicast address space,
meaning that anycast addresses are not semantically
distinguishable from unicast addresses.
Global unicast addresses consist of an n-bit global routing prefix, m
bits of subnet ID and 128-n-m bits of an interface ID. All global
unicast addresses other than those that start with binary 000 have a
64-bit interface ID field. Global unicast addresses starting with
binary 000 have no constraint on size or structure of interface ID
field. An example of use of global unicast addresses starting with
binary 000 are the IPv6 addresses that are used to map IPv4 addresses
to the IPv6 address space.
Nodes and routers are required to recognise certain addresses as
meaning themselves, as follows:
o Nodes
* A link-local address for each interface.
* Any additional unicast or anycast addresses that have been
configured for the node's interfaces, either manually or
automatically.
* The loopback address.
* The All-Nodes multicast addresses.
O'Reilly Expires October 26, 2018 [Page 6]
Internet-Draft IPv6 Crime Attribution April 2018
* The Solicited-Node multicast address for each of its unicast
and anycast addresses.
* Multicast addresses of all other groups to which the node
belongs.
o Routers
* All addresses that nodes must recognise.
* The Subnet-Router anycast address for all interfaces for which
it is configured to act as a router.
* All other Anycast addresses with which the router has been
configured.
* The All-Routers multicast addresses.
2. IPv6 Endpoint Address Assignment
2.1. Manual IPv6 Address Configuration
Similar to the way that IPv4 addresses can be manually assigned to
hosts, IPv6 addresses can also be manually assigned. This is most
frequently used in cases such as address assignment to routers or
other infrastructure components, such as servers. Because IPv6
addresses are significantly less human-readable than IPv4 addresses,
several address patterns have been noted [RFC7707]:
o Low-byte addresses, where most of the bytes of the interface
identifier are set to zero, except for the least significant byte.
For example, 2001:db8::1, 2001:db8::2, etc..
o IPv4 addresses, in which the interface identifier embeds the IPv4
address of the network interface. For example,
2001:db8::192.168.0.2.
o Service port addresses, where the interface identifier embeds the
TCP/UDP port of the main service running on the node. For
example, 2001:db8::80.
o Wordy addresses that encode words. For example,
2001:db8::dead:beef.
O'Reilly Expires October 26, 2018 [Page 7]
Internet-Draft IPv6 Crime Attribution April 2018
2.1.1. Crime Attribution Characteristics
2.1.1.1. Locating a host using a manually assigned IPv6 address
While it is expected that this address assignment technique is more
likely to be used with infrastructure components rather than user
hosts/endpoints, there is no reason in principle why endpoints could
not have manually assigned IPv6 addresses. In such cases, the IT
function in the organisation ought to have some process by which IPv6
addresses are selected for hosts.
Even if there is no such process, network monitoring could be carried
out to isolate which host has been configured with a particular
address, presuming the IPv6 address is still active on the network.
Care must be taken to address the risk that a rogue client has
temporarily used the IPv6 address that has been legitimately assigned
to a different host while that legitimate host is inactive on the
network.
In any case, the exact same problems arise with IPv4 and such issues
are within the scope of normal investigative methodology.
2.1.1.2. Rogue clients
Challenges can arise where a rogue host bypasses the organisational
address assignment technique (e.g. DHCP), manually selecting an IPv6
address from the available space. Countermeasures can be deployed to
address this risk, such as whitelisting of link-layer addresses,
association of the link-layer addresses with specific IP addresses or
other layer two authentication mechanisms.
Once again, this is not a problem that is unique to IPv6 and is not
considered further here.
2.2. DHCPv6
DHCPv6[RFC3315] allows servers to provide configuration, including
IPv6 addresses, to IPv6 nodes. Clients and servers exchange DHCP
messages using UDP. The client uses a link-local address or
addresses determined through other mechanisms for transmitting and
receiving DHCP messages. DHCP servers receive messages from clients
using a reserved link-scoped multicast address. DHCP clients
transmit most messages to this reserved multicast address, so the
client does not need to be configured with the address or addresses
of DHCP servers.
To request assignment of one or more addresses, a client locates a
DHCP server and then requests the assignment of addresses and other
O'Reilly Expires October 26, 2018 [Page 8]
Internet-Draft IPv6 Crime Attribution April 2018
configuration information from the server. IPv6 addresses that are
assigned to the client have associated preferred and valid lifetimes,
which are specified by the server.
Two advantages of IPv6 are that support for multicast is required and
nodes can create link-local addresses during initialization. The
availability of these features means that a client can use its link-
local address and a well-known multicast address to discover and
communicate with DHCP servers or relay agents on its link.
When a DHCP server assigns address(es) to a client, these addresses
are encapsulated and provided to the client in a structure known as
an identity association. A client may request the assignment of
temporary or non-temporary addresses and different types of identity
association will be used for each case. DHCP handling of address
assignment is, however, no different for temporary addresses. The
DHCP says nothing about details of the rules for generating
successive temporary addresses, how clients use temporary addresses,
rules for generating successive temporary addresses, etc. Clients
ask for temporary addresses and servers assign them.
When a server is assigning temporary addresses, the identity
association will carry one "set" of temporary addresses - that is, at
most one address from each prefix assigned to the link to which the
client is attached. Each address can have a separate valid and
preferred lifetime associated with it. Requesting new temporary
addresses from the server is the equivalent of generating new
temporary addresses as described in [RFC4941]. The server will
generate new temporary addresses and return them to the client. The
client should request new temporary addresses before the lifetimes on
the previously assigned addresses expire. A client may send a
request to the server to have the lifetimes of temporary addresses
extended.
In a message sent by a client to a server, values in the preferred
and valid lifetime fields indicate the client's preference for those
parameters. The client may send zero in these fields if it has no
preference for the preferred and valid lifetimes. In a message sent
by a server to a client, the client must use the values in the
preferred and valid lifetime fields for the preferred and valid
lifetimes.
2.2.1. Crime Attribution Characteristics
O'Reilly Expires October 26, 2018 [Page 9]
Internet-Draft IPv6 Crime Attribution April 2018
2.2.1.1. Availability of Attribution Records
Stateful assignment of addresses using DHCP is amenable to retention
of appropriate records.
At the present time, where DHCPv4 is in widespread use, it is
uncommon for address mappings to be retained by organisations for
extended periods of time indicating which hosts had which IP
addresses at a particular time, particularly for smaller deployments.
There is no reason to believe that the situation will be any
different with the widespread deployment of DHCPv6.
2.2.1.2. Rogue clients
There is a risk that an invalid client, masquerading as a valid
client, can interact with a DHCP server and obtain valid addresses.
The motivation for this may be for theft of service, or to circumvent
auditing for any number of nefarious purposes.
DHCP authentication provides for authentication of the identity of
DHCP clients and servers, and for the integrity of messages delivered
between DHCP clients and servers. DHCP authentication does not
provide any privacy for the contents of DHCP messages. The Delayed
Authentication protocol described in section 21.4 of the DHCPv6
specification uses a secret key that is shared between a client and a
server. The use of a "DHCP realm" in the shared key allows
identification of administrative domains so that a client can select
the appropriate key or keys when roaming between administrative
domains. However, the Delayed Authentication protocol does not
define any mechanism for sharing of keys, so a client may require
separate keys for each administrative domain it encounters. The use
of shared keys may not scale well and does not provide for
repudiation of compromised keys.
2.3. 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
O'Reilly Expires October 26, 2018 [Page 10]
Internet-Draft IPv6 Crime Attribution April 2018
combining these two. In the absence of a router, hosts generate only
link-local addresses. Autoconfiguration is only possible on
multicast-capable links.
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.
2.3.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],
O'Reilly Expires October 26, 2018 [Page 11]
Internet-Draft IPv6 Crime Attribution April 2018
[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
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.
2.3.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
O'Reilly Expires October 26, 2018 [Page 12]
Internet-Draft IPv6 Crime Attribution April 2018
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 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.
O'Reilly Expires October 26, 2018 [Page 13]
Internet-Draft IPv6 Crime Attribution April 2018
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
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.
2.3.3. Crime Attribution Characteristics
2.3.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
O'Reilly Expires October 26, 2018 [Page 14]
Internet-Draft IPv6 Crime Attribution April 2018
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.
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.
2.3.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.
2.3.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.
O'Reilly Expires October 26, 2018 [Page 15]
Internet-Draft IPv6 Crime Attribution April 2018
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.
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.4. IPv4 and IPv6 Coexistence
Transitional technologies relate to the period during which IPv4 and
IPv6 must co-exist on the Internet. The problem can be broken down
into the following categories:
o Delivering traffic originating from an IPv4 node to an IPv6 node.
o Delivering traffic originating from an IPv6 node to an IPv4 node.
o Delivering traffic originating from an IPv4 node to another IPv4
node over an IPv6 transit network.
o Delivering traffic originating from an IPv6 node to another IPv6
node over an IPv4 transit network.
Two broad categories of technologies exist to facilitate this
transition. The first is mapping/translation ([RFC6052], [RFC7915],
[RFC6219], [RFC7757], [RFC6791], [RFC6146], [RFC3142], [RFC2529],
[RFC6877], [RFC7599]) and the second is tunnelling ([RFC4213],
[RFC3056], [RFC5214], [RFC4380], [RFC5569], [RFC5969], [RFC7600],
[RFC7040], [RFC7596], [RFC7597]). Some technologies incorporate
aspects of both mapping/translation and tunnelling ([RFC6877],
[RFC6333]).
Only the crime attribution characteristics of the address mapping
involved in these technologies are considered here. Additionally,
for the purposes of this document, technologies that relate to
extending the lifetime of IPv4 (such as Carrier-Grade NAT) are out of
scope. The crime attribution characteristics of these technologies
are discussed elsewhere [RFC6302], [I-D.daveor-cgn-logging].
O'Reilly Expires October 26, 2018 [Page 16]
Internet-Draft IPv6 Crime Attribution April 2018
2.4.1. Crime Attribution Characteristics
2.4.1.1. Mapping/Translation Technologies
Stateless mapping technologies involve algorithmic mapping between an
IPv4 address and an IPv6 address. Generally this is achieved through
one of a number of techniques for embedding an IPv4 address within an
IPv6 address. For example, through the use of a well-known prefix
[RFC6052], using a subset of a global prefix [RFC6052], [RFC6219] or
through a lookup table [RFC7757]. In special cases, mapping to a
specific (or small range) of IPv4 addresses is also possible
[RFC6791].
Stateful mapping technologies involve recording mappings between
addresses at intermediate translation infrastructure. Often mapping
from an IPv4 source to IPv6 destination is achieved via stateless
algorithmic mapping, with IPv6 source to IPv4 destination mapping
taking place using some sort of stateful mapping between IPv6 address
and IPv4 address plus port number [RFC6146].
[RFC6052] cites a security concern arising from embedding of a fake
IPv4 address in an IPv6 address as the source of a malicious packet.
After translation the packet will appear as an IPv4 address from the
specified (fake) source, and identification of the true source will
be extremely difficult, relying on the translation records of the
mapping infrastructure. Without mitigation this attack could allow
malicious IPv6 nodes to spoof arbitrary IPv4 addresses. To mitigate
this, reverse path checks are required to verify that the packets are
coming from the expected topological direction.
2.4.1.2. Tunnelling Technologies
IPv6 tunnelling over IPv4 is achieved by provision of a virtual link
using IPv4 as the lower-layer transport. Tunnelling of this type is
most frequently performed between two router endpoints in which one
router encapsulates the IPv6 packet in IPv4, forwards it to the other
router where it is decapsulated and forwarded as an IPv6 packet.
Similar tunnelling of IPv4 over IPv6 to facilitate the later stages
of IPv6 migration is also possible.
Particular care must be taken to make sure that tunnelling
technologies do not enable bypassing of ingress filtering, which
could lead to injection of IPv6 packets into the encapsulation tunnel
and these packets being successfully decapsulated and forwarded.
In some cases, traffic is accepted and decapsulated from any source
from which IPv4 traffic would normally be accepted. This leads to a
risk of "traffic laundering" where traffic is channelled through
O'Reilly Expires October 26, 2018 [Page 17]
Internet-Draft IPv6 Crime Attribution April 2018
third parties to make tracing the real origin of the attack more
difficult [RFC3056], [RFC3964].
2.5. IPv6 Mobility Addresses
[RFC6275] describes Mobile IPv6, a protocol that allows nodes to
remain reachable while moving around in the IPv6 Internet. As a
fundamental service in an IPv6 stack, it is expected that Mobile IPv6
will be deployed in most nodes of the Internet. [RFC6275] provides
an excellent description of the basic operation of Mobile IPv6, from
which this section borrows heavily.
Each node is always identified by its "home address", regardless of
its current point of attachment to the Internet. The "home address"
is an IP address assigned to the mobile node within its home subnet
prefix on its home link. While situated away from home, a mobile
node is also associated with a "care-of address", which provides
information about the mobile node's current location. A care-of
address is an IP address associated with a mobile node that has the
subnet prefix of a particular foreign link. The mobile node can
acquire its care-of address through conventional IPv6 mechanisms,
such as stateless or stateful auto-configuration.
IPv6 packets addressed to the mobile node's home address are
transparently routed to its care-of address. The protocol enables
IPv6 nodes to cache the binding of a mobile node's home address with
its care-of address and then to send any packets destined for the
mobile node directly to it at this care-of address.
The association between a mobile node's home address and care-of
address is known as a "binding" for the mobile node. While away from
home, a mobile node registers its primary care-of address with a
router on its home link, requesting this router to function as the
"home agent" for the mobile node. The mobile node performs this
binding registration by sending a "Binding Update" message to the
home agent. The home agent replies to the mobile node by returning a
"Binding Acknowledgement" message.
Any node communicating with a mobile node is referred to as a
"correspondent node" of the mobile node. There are two possible
modes for communications between the mobile node and a correspondent
mode. The first mode, bidirectional tunnelling, does not require
Mobile IPv6 support from the correspondent node. Packets from the
correspondent node are routed to the home agent and then tunnelled to
the mobile node. Packets to the correspondent node are tunnelled
from the mobile node to the home agent ("reverse tunnelled") and then
routed normally from the home network to the correspondent node. In
this mode, the home agent uses proxy Neighbour Discovery to intercept
O'Reilly Expires October 26, 2018 [Page 18]
Internet-Draft IPv6 Crime Attribution April 2018
any IPv6 packets addressed to the mobile node's home address (or home
addresses) on the home link. Each intercepted packet is tunnelled to
the mobile node's care-of address using IPv6 encapsulation.
The second mode is known as "route optimisation". Packets from the
correspondent node can be routed directly to the care-of address of
the mobile node. When sending a packet to any IPv6 destination, the
correspondent node checks its cached bindings for an entry for the
packet's destination address. If a cached binding for this
destination address is found, the node uses a new type of IPv6
routing header to route the packet to the mobile node by way of the
care-of address indicated in this binding. Routing packets directly
to the mobile node's care-of address allows the shortest
communication path to be used.
While a mobile node is away from home, it continues to use its home
address, as well as also using one or more care-of addresses. When
sending a packet while away from home, a mobile node may choose among
these in selecting the address that it will use as the source of the
packet as follows:
o Protocols layered over IP will generally treat the mobile node's
home address as its IP source address for most packets. For
packets that are sent as part of transport-level connections
established while the mobile node was at home, the mobile node
must use its home address. Likewise for packets that are part of
transport-level connections that the mobile node may still be
using after moving to a new location, the mobile node should use
its home address in this way. If a binding exists, the mobile
node should send the packets directly to the correspondent node.
Otherwise if a binding does not exist, the mobile node must use
reverse tunnelling.
o The mobile node may choose to directly use one of its care-of
addresses as the source of the packet, not requiring the use of a
home address option in the packet. This is particularly useful
for short-term communication that may easily be retried if it
fails. Using the mobile node's care-of address as the source for
such queries will generally have a lower overhead than using the
mobile node's home address, since no extra options need to be used
in either the query or its reply. Such packets can be routed
normally, directly between their source and destination without
relying on Mobile IPv6. If an application running on the mobile
node has no particular knowledge that the communication being sent
fits within this general type of communication, however, the
mobile node should not use its care-of address as the source of
the packet in this way. The choice of the most efficient
communications method id application specific.
O'Reilly Expires October 26, 2018 [Page 19]
Internet-Draft IPv6 Crime Attribution April 2018
o While not at its home link, the mobile node must not use the home
address destination option when communication with link-local
peers. Similarly the mobile node must not use the home address
destination option for IPv6 Neighbour discovery packets.
2.5.1. Crime Attribution Characteristics
As mentioned above, care-of addresses can be generated using normal
IPv6 mechanisms such as stateless or stateful autoconfiguration and
will presumably be assigned in accordance with the configuration of
the "care-of" network to which the node is connected.
Three issues related to crime attribution have been identified
regarding the use of Mobile IPv6. These will be discussed in the
following sections.
2.5.1.1. Attribution of the activity of the mobile node from
information available at the home network
Consider a node whose home network is "A", with a home IPv6 address
of "A1" is present on a network "B" using care-of address "B1".
To allow forwarding of traffic to A1 while it is on network B, the
node will register the binding between its home address and its care-
of address with the home agent on network "A". This registration
could, in principle at least, be recorded and made available if
needed for a criminal investigation. Therefore, the best attribution
information is likely to be available in the records of the home
network, presuming those records are retained.
It is possible that an administrator of the home network could
determine the preferred "care-of" address of a particular IPv6
address from records generated from the normal operation of the
Mobile IPv6 protocol.
However, this presumes that a law enforcement agency knows to request
information about the activity of IP address A1. It is possible that
the mobile node may choose to use the care-of address (B1 in this
example) as the source IP address in IP packets while away from home.
In these cases, it is not clear how a law enforcement agency would
even know about the relationship between the node and network A at
all. To make that link feasible requires that network "B" has
retained records of devices to which care-of addresses have been
assigned and this will be discussed in the next section.
O'Reilly Expires October 26, 2018 [Page 20]
Internet-Draft IPv6 Crime Attribution April 2018
2.5.1.2. Attribution of the activity of the mobile node from
information available at the care-of network
The mobile node has been assigned an IP address on the network B and,
in the first instance, all of the attribution issues discussed
elsewhere in this document will be applicable to the care-of address
of the mobile node.
It is not apparent from the protocol that there is any difference
between assignment of an IPv6 address to a mobile node that is
visiting the network as opposed to assignment of an IPv6 address to a
node for which it is the home network. If there is any difference,
it would appear that the differences are organisational, meaning that
addresses for mobile nodes are assigned from a different portion of
the organisation's address space or are more comprehensively
monitored, for example. There is, however, no particular reason
(from the point of view of the Mobile IPv6 protocol) why temporary
SLAAC addresses or other addresses for which no attribution records
are retained, could not be assigned as care-of addresses to mobile
nodes.
The protocol allows a mobile node to select its care-of address as
the source address in IP packets and if this communication is
criminal in nature, the records of which node was using the care-of
address at a particular point in time would become important.
There is no aspect of the protocol that requires the "care-of"
network to retain any particular records of use by mobile nodes of
care-of addresses, or to retain any record of the binding between
care-of addresses and home addresses. The hope, therefore, is that
organisations that assign care-of addresses keep records of
assignments on their network.
In summary, it may be very challenging for law enforcement
authorities to identify the home network of a particular node based
only on the care-of address and records available at the "care-of"
network.
2.5.1.3. The ephemeral nature of correspondent routing/route
optimisation information
Correspondent routing/route optimisation allows a correspondent node
to cache an association between the home and care-of addresses of the
mobile node, and forward traffic directly to the mobile node rather
than tunnel that traffic via the home agent. For the purpose of this
discussion, consider the mobile node as engaging in criminal activity
with the correspondent node being the victim or source of evidence of
the activity.
O'Reilly Expires October 26, 2018 [Page 21]
Internet-Draft IPv6 Crime Attribution April 2018
In this case, because the route optimisation is only temporarily
cached, it is highly likely that after a period of time the
correspondent node will not retain any record of the relationship
between the care-of and home addresses of the mobile node. The only
remaining record will be of the activity of the care-of address,
meaning total reliance of the records of the "care-of" network to
associate the care-of address with the home address of the mobile
node.
2.6. IPv6 Address Selection
IPv6 allows multiple unicast addresses to be assigned to interfaces.
These addresses might have different reachability scopes (link-local,
site-local or global). They might also be preferred or deprecated.
There might also be public addresses and temporary addresses. Both
the source and destination endpoints may have multiple IP addresses
by which they can communicate with each other.
[RFC6724] describes two related algorithms, one for source address
selection and one for destination address selection that can be used
by hosts when selecting IP addresses from the range of possibilities.
The document specifies default behaviour and does not override
choices made by applications or upper-layer protocols, nor does it
preclude the development of more advanced mechanisms for address
selection. In dual stack implementations, the destination address
selection algorithm can consider both IPv4 and IPv6 addresses,
depending on the available source addresses.
The algorithm uses several criteria in making decisions. The
combined effect is to prefer destination/source address pairs for
which the two addresses are of equal scope or type, prefer smaller
scopes over larger scopes for the destination address, prefer non-
deprecated source addresses, avoid the use of transitional addresses
when native addresses are available and all else being equal prefer
address pairs having the longest possible common prefix. For source
address selection, temporary addresses are preferred over public
addresses. In mobile situations, home addresses are preferred over
care-of addresses.
The default address selection document also mandates implementations
to provide a mechanism that allows an application to configure its
preference for temporary addresses over public addresses. It also
allows for an implementation to prefer temporary addresses by
default, so that the connections initiated by the node can use
temporary addresses without requiring application-specific
enablement.
O'Reilly Expires October 26, 2018 [Page 22]
Internet-Draft IPv6 Crime Attribution April 2018
2.6.1. Crime Attribution Characteristics
The preference for temporary source addresses is explicitly
incorporated into the default IPv6 address selection algorithms
outlined in [RFC6724].
This recommendation further exacerbates the challenges highlighted in
Section 2.3.2 relating to the use of temporary addresses and
increases the importance of addressing these issues.
2.7. IPv6 Edge Router Recommendations
[RFC7084] specifies requirements for an IPv6 Customer Edge (CE)
router. Specifically, the document focuses on the basic provisioning
of an IPv6 CE router and the provisioning of IPv6 hosts attached to
it. The document also covers IP transition technologies.
This document specifies, amongst other things, how an IPv6 CE router
automatically provisions its WAN interface, acquires address space
for provisioning of its LAN interfaces, and fetches other
configuration information from the service provider network.
Automatic provisioning of more complex topology than a single router
with multiple LAN interfaces is out of scope for the document.
It was noted that requirement L-8 is:
An IPv6 CE router MUST support a DHCPv6 server capable of IPv6
address assignment according to [RFC3315] OR a stateless DHCPv6
server according to [RFC3736] on its LAN interfaces.
[RFC6092] describes an additional set of recommended security
capabilities for devices at the perimeter of local-area IPv6 networks
in Internet-enabled homes and small offices.
2.7.1. Crime Attribution Characteristics
Requirement L-8, cited above indicates that the IPv6 CE router might
be assigning addresses to endpoints. No corresponding recommendation
that the router should record which addresses have been assigned to
endpoints is contained in the document. No recommendation related to
recording address assignments is contained in [RFC6092] either.
2.8. IPv6 Prefix Per Host
For reasons of improved host isolation and enhanced subscriber
management on shared network segments, there are published approaches
for assigning IPv6 prefixes to individual hosts [RFC8273], [RFC3314],
[RFC7934]. Advantages are then achieved by making sure that devices
O'Reilly Expires October 26, 2018 [Page 23]
Internet-Draft IPv6 Crime Attribution April 2018
cannot send packets to each other except through the first-hop
router.
2.8.1. Crime Attribution Characteristics
2.8.1.1. Usage of endpoint addresses
It is understood from the referenced sources that this model is
proposed for use principally in mobile networks. The crime
attribution characteristics of assignment of an IPv6 prefix per host
will depend on the use to which the host puts the prefix. For
example, in the scenario where a mobile device is acting as a
"hotspot" for other tethered devices it will no longer be possible to
attribute all activity related to any addresses with the prefix to a
specific endpoint. This scenario is specifically discussed in
[RFC3314] and [RFC7934] as an advantage of assigning IPv6 prefixes
per host.
This situation is analogous to the situation with attributing
criminal activity to a host that is attached to a wireless LAN access
point. Without appropriate security controls there is a risk that an
attacker could use an unauthorised connection to the wireless LAN
access point to commit criminal acts. Similarly in cases where an
IPv6 prefix has been assigned to a mobile device that can act as a
wireless "hotspot", unauthorised tethered devices may be able to
perform criminal acts in an untraceable way. This problem is, of
course, not specific to IPv6 because the same problem could arise
with an unauthorised tethering to a mobile device using IPv4.
2.8.1.2. Frequently changing prefixes
It has been highlighted elsewhere that the assignment of a prefix per
host could make the prefix an identifying characteristic of the host,
with the associated privacy implications
[I-D.herbert-ipv6-prefix-address-privacy]. The reference cited
proposes a high-level model involving the randomisation of addresses
to address this (referred to as identifier addresses), followed by an
address translation to a globally stable addresses (referred to as
locator addresses). The document proposes that the crime attribution
concerns of the proposed approach could be addressed by maintaining
records of the mappings between identifier and locator addresses,
meaning that from a crime attribution point of view the proposed
technology would be similar to an IPv4 NAT.
O'Reilly Expires October 26, 2018 [Page 24]
Internet-Draft IPv6 Crime Attribution April 2018
3. Conclusion
Significant consideration has been given to the privacy and security
considerations of IPv6 assignment methodologies and supporting
technologies.
However, inasmuch as IPv6 is intended to address the shortcomings of
IPv4, the shortcomings related to crime attribution do not appear to
have received sufficient consideration. In fact, the trajectory of
the work reviewed during the production of this document would seem
to indicate a significantly greater focus on architectural models to
actively obfuscate the identity of endpoints using IPv6.
Whilst individual privacy is extremely important, total privacy would
have significant negative implications for law enforcement ability to
conduct investigations of criminal activity online as well as on the
rights of victims of crime.
It is hoped that the production of this document will stimulate
further discussion on the matter.
4. IANA Considerations
This memo includes no request to IANA.
5. Security Considerations
Many of the cited documents contain security considerations for the
technologies that they define or consider and from a technical
perspective, this document does not introduce any additional security
considerations.
On the other hand, this document considers the security features of
those same technologies from a different perspective and in that
respect, this entire document is a consideration of security
implications of those technologies.
6. References
6.1. Informative References
[I-D.daveor-cgn-logging]
O'Reilly, D., "Approaches to Address the Availability of
Information in Criminal Investigations Involving Large-
Scale IP Address Sharing Technologies", draft-daveor-cgn-
logging-04 (work in progress), April 2018.
O'Reilly Expires October 26, 2018 [Page 25]
Internet-Draft IPv6 Crime Attribution April 2018
[I-D.herbert-ipv6-prefix-address-privacy]
Herbert, T., "Privacy in IPv6 Network Prefix Assignment",
draft-herbert-ipv6-prefix-address-privacy-00 (work in
progress), February 2018.
6.2. 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>.
[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>.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529,
DOI 10.17487/RFC2529, March 1999,
<https://www.rfc-editor.org/info/rfc2529>.
[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>.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February
2001, <https://www.rfc-editor.org/info/rfc3056>.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", RFC 3142, DOI 10.17487/RFC3142, June
2001, <https://www.rfc-editor.org/info/rfc3142>.
O'Reilly Expires October 26, 2018 [Page 26]
Internet-Draft IPv6 Crime Attribution April 2018
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164,
DOI 10.17487/RFC3164, August 2001,
<https://www.rfc-editor.org/info/rfc3164>.
[RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, DOI 10.17487/RFC3314, September 2002,
<https://www.rfc-editor.org/info/rfc3314>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[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>.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736,
April 2004, <https://www.rfc-editor.org/info/rfc3736>.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004,
<https://www.rfc-editor.org/info/rfc3964>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213,
DOI 10.17487/RFC4213, October 2005,
<https://www.rfc-editor.org/info/rfc4213>.
[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>.
O'Reilly Expires October 26, 2018 [Page 27]
Internet-Draft IPv6 Crime Attribution April 2018
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380,
DOI 10.17487/RFC4380, February 2006,
<https://www.rfc-editor.org/info/rfc4380>.
[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>.
[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>.
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214,
DOI 10.17487/RFC5214, March 2008,
<https://www.rfc-editor.org/info/rfc5214>.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569,
January 2010, <https://www.rfc-editor.org/info/rfc5569>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, DOI 10.17487/RFC5969, August 2010,
<https://www.rfc-editor.org/info/rfc5969>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<https://www.rfc-editor.org/info/rfc6052>.
O'Reilly Expires October 26, 2018 [Page 28]
Internet-Draft IPv6 Crime Attribution April 2018
[RFC6092] Woodyatt, J., Ed., "Recommended Simple Security
Capabilities in Customer Premises Equipment (CPE) for
Providing Residential IPv6 Internet Service", RFC 6092,
DOI 10.17487/RFC6092, January 2011,
<https://www.rfc-editor.org/info/rfc6092>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[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>.
[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The
China Education and Research Network (CERNET) IVI
Translation Design and Deployment for the IPv4/IPv6
Coexistence and Transition", RFC 6219,
DOI 10.17487/RFC6219, May 2011,
<https://www.rfc-editor.org/info/rfc6219>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers",
BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
<https://www.rfc-editor.org/info/rfc6302>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<https://www.rfc-editor.org/info/rfc6333>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G.
Huston, "Stateless Source Address Mapping for ICMPv6
Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012,
<https://www.rfc-editor.org/info/rfc6791>.
O'Reilly Expires October 26, 2018 [Page 29]
Internet-Draft IPv6 Crime Attribution April 2018
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation",
RFC 6877, DOI 10.17487/RFC6877, April 2013,
<https://www.rfc-editor.org/info/rfc6877>.
[RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public
IPv4-over-IPv6 Access Network", RFC 7040,
DOI 10.17487/RFC7040, November 2013,
<https://www.rfc-editor.org/info/rfc7040>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
Requirements for IPv6 Customer Edge Routers", RFC 7084,
DOI 10.17487/RFC7084, November 2013,
<https://www.rfc-editor.org/info/rfc7084>.
[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>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<https://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July
2015, <https://www.rfc-editor.org/info/rfc7599>.
O'Reilly Expires October 26, 2018 [Page 30]
Internet-Draft IPv6 Crime Attribution April 2018
[RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G.,
and M. Chen, "IPv4 Residual Deployment via IPv6 - A
Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600,
July 2015, <https://www.rfc-editor.org/info/rfc7600>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>.
[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>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016,
<https://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<https://www.rfc-editor.org/info/rfc7915>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>.
[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>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[RIPE_699]
RIPE, "IPv6 Address Allocation and Assignment Policy",
2016, <https://www.ripe.net/publications/docs/ripe-699>.
Author's Address
David O'Reilly
Ireland
Email: rfc@daveor.com
O'Reilly Expires October 26, 2018 [Page 31]
