[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/