Internet Engineering Task Force D. O'Reilly
Internet-Draft April 25, 2018
Intended status: Informational
Expires: October 27, 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 27, 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

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:

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:

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 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:

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:

There are no broadcast addresses in IPv6, their function being superseded by multicast addresses.

There are a number of special ranges of IPv6 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:

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]:

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 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

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 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], [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):

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 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:

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
  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 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.

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:

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].

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 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 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:

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.

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.

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.

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:

[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 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.

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", Internet-Draft draft-daveor-cgn-logging-04, April 2018.
[I-D.herbert-ipv6-prefix-address-privacy] Herbert, T., "Privacy in IPv6 Network Prefix Assignment", Internet-Draft draft-herbert-ipv6-prefix-address-privacy-00, February 2018.

6.2. Normative References

[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998.
[RFC2470] Crawford, M., Narten, T. and S. Thomas, "Transmission of IPv6 Packets over Token Ring Networks", RFC 2470, DOI 10.17487/RFC2470, December 1998.
[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.
[RFC2492] Armitage, G., Schulter, P. and M. Jork, "IPv6 over ATM Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999.
[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999.
[RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, DOI 10.17487/RFC2529, March 1999.
[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.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, DOI 10.17487/RFC3142, June 2001.
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, DOI 10.17487/RFC3164, August 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, DOI 10.17487/RFC3314, September 2002.
[RFC3315] Droms, R., 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.
[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.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, April 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, DOI 10.17487/RFC4213, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006.
[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.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, DOI 10.17487/RFC4380, February 2006.
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 2006.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.
[RFC4941] Narten, T., Draves, R. and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007.
[RFC5072] Varada, S., Haskins, D. and E. Allen, "IP Version 6 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007.
[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.
[RFC5214] Templin, F., Gleeson, T. and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, DOI 10.17487/RFC5214, March 2008.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, January 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010.
[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.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, DOI 10.17487/RFC6092, January 2011.
[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.
[RFC6177] Narten, T., Huston, G. and L. Roberts, "IPv6 Address Assignment to End Sites", BCP 157, RFC 6177, DOI 10.17487/RFC6177, March 2011.
[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.
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011.
[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.
[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.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A. and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012.
[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.
[RFC6877] Mawatari, M., Kawashima, M. and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013.
[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.
[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.
[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.
[RFC7271] Ryoo, J., Gray, E., 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.
[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.
[RFC7597] Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T. and T. Taylor, "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015.
[RFC7599] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S. and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015.
[RFC7600] Despres, R., Jiang, S., 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.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016.
[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.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T. and F. Gont, "IP/ICMP Translation Algorithm", RFC 7915, DOI 10.17487/RFC7915, June 2016.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S. and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016.
[RFC8064] Gont, F., Cooper, A., Thaler, D. and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017.
[RIPE_699] RIPE, "IPv6 Address Allocation and Assignment Policy", 2016.

Author's Address

David O'Reilly Ireland EMail: rfc@daveor.com