idnits 2.17.1 draft-daveor-ipv6-crime-attribution-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1064: '...n IPv6 CE router MUST support a DHCPv6...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 24, 2018) is 2194 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3164 (Obsoleted by RFC 5424) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. O'Reilly 3 Internet-Draft April 24, 2018 4 Intended status: Informational 5 Expires: October 26, 2018 7 Analysis of the Crime Attribution Characteristics of Various IPv6 8 Address Assignment Techniques 9 draft-daveor-ipv6-crime-attribution-00 11 Abstract 13 The migration from IPv4 to IPv6 is intended to fix a large number of 14 problems with IPv4 that have been identified through many years of 15 global use, not least of which is the shortage of available IPv4 16 addresses. One of the challenges with IPv4 that has not, apparently, 17 been adequately considered is the crime attribution characteristics 18 of IPv6 technologies. 20 The challenge of crime attribution on the Internet is an important 21 one and a careful balance needs to be struck between the needs of law 22 enforcement, the rights of crime victims and the right to privacy of 23 the vast majority of Internet users who have no involvement in any 24 sort of criminality. 26 The purpose of this document is to consider the crime attribution 27 characteristics of various IPv6 address assignment techniques. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 26, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. Background on IPv6 Address Architecture . . . . . . . . . 5 66 2. IPv6 Endpoint Address Assignment . . . . . . . . . . . . . . 7 67 2.1. Manual IPv6 Address Configuration . . . . . . . . . . . . 7 68 2.1.1. Crime Attribution Characteristics . . . . . . . . . . 8 69 2.1.1.1. Locating a host using a manually assigned IPv6 70 address . . . . . . . . . . . . . . . . . . . . . 8 71 2.1.1.2. Rogue clients . . . . . . . . . . . . . . . . . . 8 72 2.2. DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 2.2.1. Crime Attribution Characteristics . . . . . . . . . . 9 74 2.2.1.1. Availability of Attribution Records . . . . . . . 10 75 2.2.1.2. Rogue clients . . . . . . . . . . . . . . . . . . 10 76 2.3. SLAAC: Stateless Address Autoconfiguration . . . . . . . 10 77 2.3.1. Stable Address Autoconfiguration . . . . . . . . . . 11 78 2.3.2. Temporary Address Autoconfiguration . . . . . . . . . 12 79 2.3.3. Crime Attribution Characteristics . . . . . . . . . . 14 80 2.3.3.1. Stateless Address Autoconfiguration . . . . . . . 14 81 2.3.3.2. SLAAC with stable interface identifiers . . . . . 15 82 2.3.3.3. SLAAC with temporary interface identifiers . . . 15 83 2.4. IPv4 and IPv6 Coexistence . . . . . . . . . . . . . . . . 16 84 2.4.1. Crime Attribution Characteristics . . . . . . . . . . 17 85 2.4.1.1. Mapping/Translation Technologies . . . . . . . . 17 86 2.4.1.2. Tunnelling Technologies . . . . . . . . . . . . . 17 87 2.5. IPv6 Mobility Addresses . . . . . . . . . . . . . . . . . 18 88 2.5.1. Crime Attribution Characteristics . . . . . . . . . . 20 89 2.5.1.1. Attribution of the activity of the mobile node 90 from information available at the home network . 20 91 2.5.1.2. Attribution of the activity of the mobile node 92 from information available at the care-of network 21 93 2.5.1.3. The ephemeral nature of correspondent 94 routing/route optimisation information . . . . . 21 95 2.6. IPv6 Address Selection . . . . . . . . . . . . . . . . . 22 96 2.6.1. Crime Attribution Characteristics . . . . . . . . . . 23 97 2.7. IPv6 Edge Router Recommendations . . . . . . . . . . . . 23 98 2.7.1. Crime Attribution Characteristics . . . . . . . . . . 23 99 2.8. IPv6 Prefix Per Host . . . . . . . . . . . . . . . . . . 23 100 2.8.1. Crime Attribution Characteristics . . . . . . . . . . 24 101 2.8.1.1. Usage of endpoint addresses . . . . . . . . . . . 24 102 2.8.1.2. Frequently changing prefixes . . . . . . . . . . 24 103 3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 106 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 107 6.1. Informative References . . . . . . . . . . . . . . . . . 25 108 6.2. Normative References . . . . . . . . . . . . . . . . . . 26 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 IPv6 addresses are assigned to organisations in blocks that are much 114 larger than the size of the blocks in which IPv4 addresses are 115 assigned, with common IPv6 prefix sizes being /48, /56 and /64 116 [RFC6177], [RIPE_699]. Current regulatory models typically oblige 117 ISPs to keep records to facilitate identification of their 118 subscribers, and in the case of IPv6 this will mean recording the 119 prefix(es) have been assigned to each customer. 121 From the perspective of crime attribution, therefore, when a specific 122 IP address is suspected to be associated with criminal activity, 123 records will most likely available from an ISP to identify the 124 organisation to which the prefix has been assigned. The question 125 then arises how an organisation approached by law enforcement 126 authorities, particularly a large organisation, would be able to 127 ascertain which host/endpoint within their network was using a 128 particular IP address at a particular time. 130 This is not a new problem, with many difficulties of crime 131 attribution already present in the IPv4 Internet. Nevertheless, it 132 is worthwhile to consider the crime attribution characteristics of 133 IPv6 in anticipation of wider deployment of this technology in the 134 coming years. 136 IPv6 provides several mechanisms through which hosts can be assigned 137 an IP address. [RFC7721] provides a list of these. Briefly they can 138 be summarised as: 140 o Manually configured addresses 141 o DHCPv6 assigned addresses 143 o Stateless Address Autoconfiguration (SLAAC) 145 o Addresses derived from an IPv4 address (transitional) 147 When approached by a law enforcement agency to identify the host/ 148 endpoint that was using a particular IP address at a particular time, 149 the organisation's ability to deliver this information will depend on 150 how IPv6 addresses are being assigned to endpoints within their 151 network. This document considers the crime attribution 152 characteristics of the address assignment methodologies listed above. 154 The crime attribution characteristics of several related topics are 155 also considered: 157 o [RFC6275] describes Mobile IPv6, a protocol that allows nodes to 158 remain reachable while moving around in the IPv6 Internet. As a 159 fundamental service in an IPv6 stack, it is expected that Mobile 160 IPv6 will be deployed in most nodes of the Internet. Through this 161 technique, a host/endpoint would temporarily use an address from a 162 different global prefix space. 164 o It is not uncommon for a host/endpoint to have multiple IPv6 165 addresses of various scopes and, similarly, for a destination 166 host/endpoint to also have multiple IPv6 addresses that the source 167 could select to communicate with. Recommendations have been 168 published for default algorithms that hosts can use to select both 169 source and destination addresses from the available options. 170 [RFC6724] 172 o Previous work has also published requirements for IPv6 customer 173 edge routers. [RFC7084] 175 o For reasons of improved host isolation and enhanced subscriber 176 management on shared network segments, there are approaches 177 available for assigning IPv6 prefixes to individual hosts. 178 [RFC8273], [RFC3314], [RFC7934] 180 1.1. Scope 182 This document considers only one scenario, as follows; through some 183 means of investigation, an IPv6 address is suspected to be associated 184 with criminal activity. How the IPv6 address has been associated 185 with criminal activity is beyond the scope of this document - the 186 starting point of this document is that an IPv6 address has already 187 been identified (e.g. from logs of a victim or through other 188 investigative means). What are the challenges arising from the use 189 of IPv6 in attributing the activity of the suspect address to a 190 specific endpoint? 192 Other aspects of the investigative process, including those that 193 might be sources of evidence, which are out of scope of this 194 document, include: 196 o Attribution of criminal activity through identification and 197 collection of information from upper layer protocol analysis (e.g. 198 TCP flow analysis, HTTP cookies, usernames or other application- 199 layer session data). 201 o Attribution of criminal activity through the identification and 202 collection of information from non-technical sources (e.g. covert 203 investigations, crime reports, etc.) that can associate an 204 individual with the activity of a specific IPv6 address. 206 o Associating the activity of a host or endpoint with a real-world 207 human being. 209 The security considerations associated with each of the technologies 210 discussed are also out of scope except inasmuch as they influence the 211 crime attribution characteristics of the technology. 213 1.2. Background on IPv6 Address Architecture 215 The IPv6 addressing model is defined in [RFC4291]. This section 216 provides a brief summary of the salient points of the IPv6 addressing 217 model, the full detail of which can be found in the RFC. 219 In the IPv6 addressing model, addresses are assigned to interfaces, 220 not nodes. There are three types of addresses: 222 o Unicast addresses identify a single interface. 224 o Anycast addresses identify a set of interfaces. A packet sent to 225 an anycast address is delivered to one of the interfaces in the 226 set. The packet will be sent to the "nearest" interface in the 227 set, nearness being defined according to the routing protocol's 228 measure of distance. 230 o Multicast addresses identify a set of interfaces. A packet sent 231 to a multicast address is delivered to all of the interfaces in 232 the set. 234 There are no broadcast addresses in IPv6, their function being 235 superseded by multicast addresses. 237 There are a number of special ranges of IPv6 addresses: 239 o An IPv6 address consisting of all zeros is the unspecified address 240 (::/128) and this cannot be assigned to any node. 242 o An IPv6 address consisting of 127 zeros with the lowest bit being 243 1 is the loopback address (::1/128). 245 o Multicast addresses begin with the prefix FF00::/8. 247 o Link-local unicast addresses begin with the prefix FE80::/10. 248 Link-local unicast addresses are for use on a single link and will 249 not be forwarded by routers to other links. 251 o Site-local unicast addresses begin with the prefix FEC0::/10. 252 This deprecated prefix was intended for addressing within a site 253 without the need for a global prefix. New implementations must 254 treat this prefix as global unicast addresses. 256 o All other addresses are global unicast addresses. Anycast 257 addresses are also taken from the global unicast address space, 258 meaning that anycast addresses are not semantically 259 distinguishable from unicast addresses. 261 Global unicast addresses consist of an n-bit global routing prefix, m 262 bits of subnet ID and 128-n-m bits of an interface ID. All global 263 unicast addresses other than those that start with binary 000 have a 264 64-bit interface ID field. Global unicast addresses starting with 265 binary 000 have no constraint on size or structure of interface ID 266 field. An example of use of global unicast addresses starting with 267 binary 000 are the IPv6 addresses that are used to map IPv4 addresses 268 to the IPv6 address space. 270 Nodes and routers are required to recognise certain addresses as 271 meaning themselves, as follows: 273 o Nodes 275 * A link-local address for each interface. 277 * Any additional unicast or anycast addresses that have been 278 configured for the node's interfaces, either manually or 279 automatically. 281 * The loopback address. 283 * The All-Nodes multicast addresses. 285 * The Solicited-Node multicast address for each of its unicast 286 and anycast addresses. 288 * Multicast addresses of all other groups to which the node 289 belongs. 291 o Routers 293 * All addresses that nodes must recognise. 295 * The Subnet-Router anycast address for all interfaces for which 296 it is configured to act as a router. 298 * All other Anycast addresses with which the router has been 299 configured. 301 * The All-Routers multicast addresses. 303 2. IPv6 Endpoint Address Assignment 305 2.1. Manual IPv6 Address Configuration 307 Similar to the way that IPv4 addresses can be manually assigned to 308 hosts, IPv6 addresses can also be manually assigned. This is most 309 frequently used in cases such as address assignment to routers or 310 other infrastructure components, such as servers. Because IPv6 311 addresses are significantly less human-readable than IPv4 addresses, 312 several address patterns have been noted [RFC7707]: 314 o Low-byte addresses, where most of the bytes of the interface 315 identifier are set to zero, except for the least significant byte. 316 For example, 2001:db8::1, 2001:db8::2, etc.. 318 o IPv4 addresses, in which the interface identifier embeds the IPv4 319 address of the network interface. For example, 320 2001:db8::192.168.0.2. 322 o Service port addresses, where the interface identifier embeds the 323 TCP/UDP port of the main service running on the node. For 324 example, 2001:db8::80. 326 o Wordy addresses that encode words. For example, 327 2001:db8::dead:beef. 329 2.1.1. Crime Attribution Characteristics 331 2.1.1.1. Locating a host using a manually assigned IPv6 address 333 While it is expected that this address assignment technique is more 334 likely to be used with infrastructure components rather than user 335 hosts/endpoints, there is no reason in principle why endpoints could 336 not have manually assigned IPv6 addresses. In such cases, the IT 337 function in the organisation ought to have some process by which IPv6 338 addresses are selected for hosts. 340 Even if there is no such process, network monitoring could be carried 341 out to isolate which host has been configured with a particular 342 address, presuming the IPv6 address is still active on the network. 343 Care must be taken to address the risk that a rogue client has 344 temporarily used the IPv6 address that has been legitimately assigned 345 to a different host while that legitimate host is inactive on the 346 network. 348 In any case, the exact same problems arise with IPv4 and such issues 349 are within the scope of normal investigative methodology. 351 2.1.1.2. Rogue clients 353 Challenges can arise where a rogue host bypasses the organisational 354 address assignment technique (e.g. DHCP), manually selecting an IPv6 355 address from the available space. Countermeasures can be deployed to 356 address this risk, such as whitelisting of link-layer addresses, 357 association of the link-layer addresses with specific IP addresses or 358 other layer two authentication mechanisms. 360 Once again, this is not a problem that is unique to IPv6 and is not 361 considered further here. 363 2.2. DHCPv6 365 DHCPv6[RFC3315] allows servers to provide configuration, including 366 IPv6 addresses, to IPv6 nodes. Clients and servers exchange DHCP 367 messages using UDP. The client uses a link-local address or 368 addresses determined through other mechanisms for transmitting and 369 receiving DHCP messages. DHCP servers receive messages from clients 370 using a reserved link-scoped multicast address. DHCP clients 371 transmit most messages to this reserved multicast address, so the 372 client does not need to be configured with the address or addresses 373 of DHCP servers. 375 To request assignment of one or more addresses, a client locates a 376 DHCP server and then requests the assignment of addresses and other 377 configuration information from the server. IPv6 addresses that are 378 assigned to the client have associated preferred and valid lifetimes, 379 which are specified by the server. 381 Two advantages of IPv6 are that support for multicast is required and 382 nodes can create link-local addresses during initialization. The 383 availability of these features means that a client can use its link- 384 local address and a well-known multicast address to discover and 385 communicate with DHCP servers or relay agents on its link. 387 When a DHCP server assigns address(es) to a client, these addresses 388 are encapsulated and provided to the client in a structure known as 389 an identity association. A client may request the assignment of 390 temporary or non-temporary addresses and different types of identity 391 association will be used for each case. DHCP handling of address 392 assignment is, however, no different for temporary addresses. The 393 DHCP says nothing about details of the rules for generating 394 successive temporary addresses, how clients use temporary addresses, 395 rules for generating successive temporary addresses, etc. Clients 396 ask for temporary addresses and servers assign them. 398 When a server is assigning temporary addresses, the identity 399 association will carry one "set" of temporary addresses - that is, at 400 most one address from each prefix assigned to the link to which the 401 client is attached. Each address can have a separate valid and 402 preferred lifetime associated with it. Requesting new temporary 403 addresses from the server is the equivalent of generating new 404 temporary addresses as described in [RFC4941]. The server will 405 generate new temporary addresses and return them to the client. The 406 client should request new temporary addresses before the lifetimes on 407 the previously assigned addresses expire. A client may send a 408 request to the server to have the lifetimes of temporary addresses 409 extended. 411 In a message sent by a client to a server, values in the preferred 412 and valid lifetime fields indicate the client's preference for those 413 parameters. The client may send zero in these fields if it has no 414 preference for the preferred and valid lifetimes. In a message sent 415 by a server to a client, the client must use the values in the 416 preferred and valid lifetime fields for the preferred and valid 417 lifetimes. 419 2.2.1. Crime Attribution Characteristics 420 2.2.1.1. Availability of Attribution Records 422 Stateful assignment of addresses using DHCP is amenable to retention 423 of appropriate records. 425 At the present time, where DHCPv4 is in widespread use, it is 426 uncommon for address mappings to be retained by organisations for 427 extended periods of time indicating which hosts had which IP 428 addresses at a particular time, particularly for smaller deployments. 429 There is no reason to believe that the situation will be any 430 different with the widespread deployment of DHCPv6. 432 2.2.1.2. Rogue clients 434 There is a risk that an invalid client, masquerading as a valid 435 client, can interact with a DHCP server and obtain valid addresses. 436 The motivation for this may be for theft of service, or to circumvent 437 auditing for any number of nefarious purposes. 439 DHCP authentication provides for authentication of the identity of 440 DHCP clients and servers, and for the integrity of messages delivered 441 between DHCP clients and servers. DHCP authentication does not 442 provide any privacy for the contents of DHCP messages. The Delayed 443 Authentication protocol described in section 21.4 of the DHCPv6 444 specification uses a secret key that is shared between a client and a 445 server. The use of a "DHCP realm" in the shared key allows 446 identification of administrative domains so that a client can select 447 the appropriate key or keys when roaming between administrative 448 domains. However, the Delayed Authentication protocol does not 449 define any mechanism for sharing of keys, so a client may require 450 separate keys for each administrative domain it encounters. The use 451 of shared keys may not scale well and does not provide for 452 repudiation of compromised keys. 454 2.3. SLAAC: Stateless Address Autoconfiguration 456 IPv6 Stateless Address Autoconfiguration (SLAAC) describes the 457 process used by a host in deciding how to auto configure its 458 interfaces in IPv6[RFC4862]. This includes generating a link-local 459 address, generating global addresses via stateless address 460 autoconfiguration and then using duplicate address detection to 461 verify the uniqueness of the addresses on the link. SLAAC requires 462 no manual configuration of hosts, minimal (if any) configuration of 463 routers, and no additional servers. 465 Routers advertise prefixes that identify the subnet(s) associated 466 with a link and hosts generate an interface identifier that uniquely 467 identifies an interface on a subnet. An address is formed by 468 combining these two. In the absence of a router, hosts generate only 469 link-local addresses. Autoconfiguration is only possible on 470 multicast-capable links. 472 The process begins by generating a link-local address for the 473 interface. This is achieved by appending the interface identifier to 474 the well-known link-local prefix. At this point, the address is 475 considered "tentative" because it might be in use by another host on 476 the network. The host verifies the uniqueness of the address by 477 sending a Neighbour Solicitation message containing the tentative 478 address. If the address is already in use, the node that is using 479 that address will send back a Neighbour Advertisement message. If 480 the address is not unique, auto configuration stops and manual 481 configuration is required or an alternative interface identifier can 482 be used, if one is configured. 484 Once it has been established that the link-local address is unique, 485 it is assigned to the interface. Next, the host listens for a Router 486 Advertisement message or, if the host does not want to wait, it can 487 send a Router Solicitation message to the all-routers multicast 488 group. 490 Router Advertisement messages contain zero or more prefix information 491 options that contain information that can be used to generate global 492 addresses. Hosts can use stateless address autoconfiguration and 493 DHCPv6 simultaneously if they want. If the Router Advertisement 494 indicates that the prefixes can be used for autoconfiguration (by 495 setting the "autonomous address-configuration flag" in the Prefix 496 Information option field) it will also include a subnet prefix and 497 lifetime values, indicating how long addresses created from this 498 prefix will remain preferred and valid. Hosts process all Router 499 Advertisements that are received periodically, adding to and 500 refreshing the information received in previous advertisements. 502 Crucial to the crime attribution properties of SLAAC is the selection 503 of interface identifier. Various algorithms exist for the generation 504 of interface identifiers, depending on whether the interface 505 identifier is intended to be stable (long-lived) or temporary. The 506 following two sub-sections describe stable and temporary interface 507 identifier generation algorithms. 509 2.3.1. Stable Address Autoconfiguration 511 Originally, various standards specified that the interface identifier 512 should be generated from the link-layer address of the interface. 513 For example [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], 514 [RFC2590], [RFC3164], [RFC3527], [RFC4338], [RFC4391], [RFC5072], 516 [RFC5121]. This is used in cases where a stable IPv6 address is 517 being generated. 519 [RFC8064] changes the recommended default interface identifier 520 generation scheme when SLAAC is in use to generate stable IPv6 521 addresses. It recommends against embedding stable link-layer 522 addresses in IPv6 interface identifiers, recommending instead the use 523 of a semantically opaque value as defined in [RFC7217] over all other 524 alternatives. [RFC8064] also highlights some reasons why a stable 525 IPv6 address would be desirable. For example, network management, 526 event logging, enforcement of access control, provision of quality of 527 service or for server or router interfaces. Similarly, they allow 528 long-lived TCP connections. However, the document does not make 529 recommendations about WHEN stable addresses should be used and when 530 temporary addresses should be used. 532 [RFC7271] describes a method where an IPv6 address can be configured 533 in such a way that it is stable within each subnet but the interface 534 identifier changes when the host moves from one network to another. 535 In general terms, the approach is to pass the following values to a 536 cryptographic hash function (such as SHA1 or SHA256): 538 o The network prefix 540 o The network interface id 542 o The network id (subnet, SSID or similar) - optional parameter 544 o A duplicate address detection counter - incremented in case of a 545 duplicate address being generated 547 o A secret key (128 bits long at least) 549 The interface identifier is generated by taking as many bits, 550 starting at the least significant, as required. The result is an 551 opaque bit stream that can be used as the interface id. 553 2.3.2. Temporary Address Autoconfiguration 555 [RFC4941] describes a system by which interface identifiers generated 556 from an IEEE identifier (EUI-64) can be changed over time, even in 557 cases where the interface contains an embedded IEEE identifier. 558 These are referred to as temporary addresses. 560 The reason behind development of this technique is that the use of a 561 globally unique, non-changing, interface identifier means that the 562 activity of a specific interface can be tracked even if the network 563 prefix changes. The use of a fixed identifier in multiple contexts 564 allows correlation of seemingly unrelated activity using the 565 identifier. Contrast this with IPv4 addresses, where if a person 566 changes to a different network their entire IP address will change. 568 The goals of the temporary address generation procedure are that: 570 o Temporary address generation does not result in any changes to the 571 basic behaviour of addresses generated via SLAAC. 573 o The temporary address generation algorithm creates additional 574 addresses based on a random interface identifier for the purpose 575 of initiating outgoing sessions. These temporary addresses would 576 be used for a short period of time (hours to days) and would then 577 be deprecated. 579 o The algorithm produces a sequence of temporary global scope 580 addresses from the sequence of interface identifiers that appear 581 to be random in the sense that it is difficult for an outside 582 observer to predict a future address (or identifier) based on the 583 current one, or to determine a previous address (or identifier) 584 knowing only the current one. 586 o By default, the algorithm generates a set of addresses from the 587 same interface identifier, one for each prefix for which a global 588 address has been generated via SLAAC. Using the same interface 589 identifier to generate a set of temporary addresses reduces the 590 number of IP multicast groups that a host must join. 592 o A node highly concerned about privacy may use different 593 identifiers for different prefixes, resulting in a set of global 594 addresses that cannot be easily tied to each other. 596 To prevent the generation of predictable values, the algorithm must 597 contain an unpredictable component. The algorithm assumes that each 598 interface maintains an associated randomised interface identifier. 599 When temporary addresses are generated, the current value of the 600 interface identifier is used. The algorithm also assumes that for a 601 given temporary address, the implementation can determine the prefix 602 from which it was generated. 604 Two approaches to generate random interface identifiers are presented 605 in [RFC4941], depending on whether stable storage is present. 607 When stable storage is present, it is assumed that a 64-bit history 608 value is available and can be used. This value is generated as 609 described below. The first time the system boots, a random value is 610 selected. 612 1. Take the history value and append it to the interface identifier 613 generated as described in [RFC4291]. 615 2. Compute the MD5 of the resulting value 617 3. Take the leftmost 64 bits and set bit 6 to zero. (This creates 618 an interface identifier with the universal/local bit indicating 619 local significance only) 621 4. Compare the generated identifier against a list of reserved 622 identifiers and to those already assigned to an address on the 623 local device. If an unacceptable value has been generated, start 624 again at step 1. 626 5. Save the generated identifier. 628 6. Take the rightmost 64 bits and save them to state storage as the 629 history value for the next iteration of the algorithm. 631 When stable storage is not present, no history value will be 632 available. Therefore, the initial history value should be generated 633 at random. Algorithms other than MD5 can be used to compute the 634 temporary address if desired. 636 Other approaches such as cryptographically generated addresses (CGA) 637 can be used to generate random interface identifiers based on the 638 public key of the node [RFC3972]. The goal of CGAs is to prove 639 ownership of an address and prevent spoofing and stealing of IPv6 640 addresses. The CGA process may not be suitable for privacy addresses 641 because (a) it requires nodes to have a public key, meaning the node 642 can be identified by the key and (b) it is computationally intensive, 643 discouraging frequent regeneration. 645 Devices implementing this specification must provide a way for end 646 users to explicitly enable or disable the use of temporary addresses. 647 Also, sites might wish to disable it, so implementations should 648 provide a way for trusted system administrators to enable or disable 649 the use of temporary addresses. Implementations should also provide 650 a way to enable and disable generation of temporary addresses for 651 specific prefix subranges. 653 2.3.3. Crime Attribution Characteristics 655 2.3.3.1. Stateless Address Autoconfiguration 657 IPv6 addresses are assigned to organisations in blocks much larger 658 than the size of the blocks in which IPv4 addresses are assigned. 659 The question arises about how an organisation approached by law 660 enforcement authorities, particularly a large organisation, will be 661 able to ascertain which host/endpoint within their organisation was 662 using a particular IP address at a particular time when addresses 663 have been assigned using SLAAC. 665 From the crime attribution perspective, both the recommended stable 666 and temporary address generation algorithms pseudo-randomly select 667 addresses from the space of available addresses. When SLAAC is being 668 used, the hosts auto-configure the IP addresses of their interfaces, 669 meaning there is no organisational record of the IP addresses that 670 have been selected by particular hosts at particular points in time. 672 2.3.3.2. SLAAC with stable interface identifiers 674 From a crime attribution point of view, the use of a stable interface 675 identifier (whether generated for a link-local address or otherwise) 676 will provide some measure of assurance that it will be possible to 677 identify a specific host/interface based on the IPv6 address. While 678 it may not be possible for a network administrator to calculate the 679 interface identifier (and therefore the IPv6 address) that will be 680 used by a specific interface, due to the presence of a secret key, 681 with some effort it should be possible for a network operator to 682 determine which host/endpoint, or at least a relatively small subset 683 of hosts/endpoints, is responsible for traffic arising from a 684 particular IPv6 address. 686 Due to the relatively long-term use of a particular address by an 687 interface, it is at least possible that an organisation might be able 688 to use traffic flow analysis or other similar network monitoring 689 techniques to identify the endpoint using the address. This assumes 690 that the IPv6 address is still active and generating traffic. It 691 will also, of course, only identify the endpoint using the address at 692 the time of the traffic flow analysis and not at the time of the 693 alleged criminal activity that is under investigation. 695 2.3.3.3. SLAAC with temporary interface identifiers 697 The problem of crime attribution is exacerbated in the case of 698 temporary interface identifier generation due to the fact that the 699 generated addresses are the endpoint's preferred IPv6 address, by 700 default, for a period of one day [RFC4941]. 702 It is difficult to see how the activity of IPv6 addresses generated 703 using temporary interface identifiers could be attributed to any 704 host/endpoint. The interface identifier generation algorithm has a 705 cryptographic component, meaning that the addresses will appear to be 706 pseudo-randomly selected from the range of available addresses. 708 Even presuming that the host/endpoint is still active and generating 709 traffic there is no apparent way to associate the activity of the 710 host/endpoint's current address with the address in use at the time 711 of the alleged criminal activity. 713 This attribution problem is "by design", arising from the expected 714 behaviour of SLAAC with temporary interface identifiers. It 715 therefore seems that the crime attribution challenges that will arise 716 from the use of this technology have not been given due 717 consideration. The use of this technology will likely become a 718 significant crime attribution challenge in future. 720 2.4. IPv4 and IPv6 Coexistence 722 Transitional technologies relate to the period during which IPv4 and 723 IPv6 must co-exist on the Internet. The problem can be broken down 724 into the following categories: 726 o Delivering traffic originating from an IPv4 node to an IPv6 node. 728 o Delivering traffic originating from an IPv6 node to an IPv4 node. 730 o Delivering traffic originating from an IPv4 node to another IPv4 731 node over an IPv6 transit network. 733 o Delivering traffic originating from an IPv6 node to another IPv6 734 node over an IPv4 transit network. 736 Two broad categories of technologies exist to facilitate this 737 transition. The first is mapping/translation ([RFC6052], [RFC7915], 738 [RFC6219], [RFC7757], [RFC6791], [RFC6146], [RFC3142], [RFC2529], 739 [RFC6877], [RFC7599]) and the second is tunnelling ([RFC4213], 740 [RFC3056], [RFC5214], [RFC4380], [RFC5569], [RFC5969], [RFC7600], 741 [RFC7040], [RFC7596], [RFC7597]). Some technologies incorporate 742 aspects of both mapping/translation and tunnelling ([RFC6877], 743 [RFC6333]). 745 Only the crime attribution characteristics of the address mapping 746 involved in these technologies are considered here. Additionally, 747 for the purposes of this document, technologies that relate to 748 extending the lifetime of IPv4 (such as Carrier-Grade NAT) are out of 749 scope. The crime attribution characteristics of these technologies 750 are discussed elsewhere [RFC6302], [I-D.daveor-cgn-logging]. 752 2.4.1. Crime Attribution Characteristics 754 2.4.1.1. Mapping/Translation Technologies 756 Stateless mapping technologies involve algorithmic mapping between an 757 IPv4 address and an IPv6 address. Generally this is achieved through 758 one of a number of techniques for embedding an IPv4 address within an 759 IPv6 address. For example, through the use of a well-known prefix 760 [RFC6052], using a subset of a global prefix [RFC6052], [RFC6219] or 761 through a lookup table [RFC7757]. In special cases, mapping to a 762 specific (or small range) of IPv4 addresses is also possible 763 [RFC6791]. 765 Stateful mapping technologies involve recording mappings between 766 addresses at intermediate translation infrastructure. Often mapping 767 from an IPv4 source to IPv6 destination is achieved via stateless 768 algorithmic mapping, with IPv6 source to IPv4 destination mapping 769 taking place using some sort of stateful mapping between IPv6 address 770 and IPv4 address plus port number [RFC6146]. 772 [RFC6052] cites a security concern arising from embedding of a fake 773 IPv4 address in an IPv6 address as the source of a malicious packet. 774 After translation the packet will appear as an IPv4 address from the 775 specified (fake) source, and identification of the true source will 776 be extremely difficult, relying on the translation records of the 777 mapping infrastructure. Without mitigation this attack could allow 778 malicious IPv6 nodes to spoof arbitrary IPv4 addresses. To mitigate 779 this, reverse path checks are required to verify that the packets are 780 coming from the expected topological direction. 782 2.4.1.2. Tunnelling Technologies 784 IPv6 tunnelling over IPv4 is achieved by provision of a virtual link 785 using IPv4 as the lower-layer transport. Tunnelling of this type is 786 most frequently performed between two router endpoints in which one 787 router encapsulates the IPv6 packet in IPv4, forwards it to the other 788 router where it is decapsulated and forwarded as an IPv6 packet. 789 Similar tunnelling of IPv4 over IPv6 to facilitate the later stages 790 of IPv6 migration is also possible. 792 Particular care must be taken to make sure that tunnelling 793 technologies do not enable bypassing of ingress filtering, which 794 could lead to injection of IPv6 packets into the encapsulation tunnel 795 and these packets being successfully decapsulated and forwarded. 797 In some cases, traffic is accepted and decapsulated from any source 798 from which IPv4 traffic would normally be accepted. This leads to a 799 risk of "traffic laundering" where traffic is channelled through 800 third parties to make tracing the real origin of the attack more 801 difficult [RFC3056], [RFC3964]. 803 2.5. IPv6 Mobility Addresses 805 [RFC6275] describes Mobile IPv6, a protocol that allows nodes to 806 remain reachable while moving around in the IPv6 Internet. As a 807 fundamental service in an IPv6 stack, it is expected that Mobile IPv6 808 will be deployed in most nodes of the Internet. [RFC6275] provides 809 an excellent description of the basic operation of Mobile IPv6, from 810 which this section borrows heavily. 812 Each node is always identified by its "home address", regardless of 813 its current point of attachment to the Internet. The "home address" 814 is an IP address assigned to the mobile node within its home subnet 815 prefix on its home link. While situated away from home, a mobile 816 node is also associated with a "care-of address", which provides 817 information about the mobile node's current location. A care-of 818 address is an IP address associated with a mobile node that has the 819 subnet prefix of a particular foreign link. The mobile node can 820 acquire its care-of address through conventional IPv6 mechanisms, 821 such as stateless or stateful auto-configuration. 823 IPv6 packets addressed to the mobile node's home address are 824 transparently routed to its care-of address. The protocol enables 825 IPv6 nodes to cache the binding of a mobile node's home address with 826 its care-of address and then to send any packets destined for the 827 mobile node directly to it at this care-of address. 829 The association between a mobile node's home address and care-of 830 address is known as a "binding" for the mobile node. While away from 831 home, a mobile node registers its primary care-of address with a 832 router on its home link, requesting this router to function as the 833 "home agent" for the mobile node. The mobile node performs this 834 binding registration by sending a "Binding Update" message to the 835 home agent. The home agent replies to the mobile node by returning a 836 "Binding Acknowledgement" message. 838 Any node communicating with a mobile node is referred to as a 839 "correspondent node" of the mobile node. There are two possible 840 modes for communications between the mobile node and a correspondent 841 mode. The first mode, bidirectional tunnelling, does not require 842 Mobile IPv6 support from the correspondent node. Packets from the 843 correspondent node are routed to the home agent and then tunnelled to 844 the mobile node. Packets to the correspondent node are tunnelled 845 from the mobile node to the home agent ("reverse tunnelled") and then 846 routed normally from the home network to the correspondent node. In 847 this mode, the home agent uses proxy Neighbour Discovery to intercept 848 any IPv6 packets addressed to the mobile node's home address (or home 849 addresses) on the home link. Each intercepted packet is tunnelled to 850 the mobile node's care-of address using IPv6 encapsulation. 852 The second mode is known as "route optimisation". Packets from the 853 correspondent node can be routed directly to the care-of address of 854 the mobile node. When sending a packet to any IPv6 destination, the 855 correspondent node checks its cached bindings for an entry for the 856 packet's destination address. If a cached binding for this 857 destination address is found, the node uses a new type of IPv6 858 routing header to route the packet to the mobile node by way of the 859 care-of address indicated in this binding. Routing packets directly 860 to the mobile node's care-of address allows the shortest 861 communication path to be used. 863 While a mobile node is away from home, it continues to use its home 864 address, as well as also using one or more care-of addresses. When 865 sending a packet while away from home, a mobile node may choose among 866 these in selecting the address that it will use as the source of the 867 packet as follows: 869 o Protocols layered over IP will generally treat the mobile node's 870 home address as its IP source address for most packets. For 871 packets that are sent as part of transport-level connections 872 established while the mobile node was at home, the mobile node 873 must use its home address. Likewise for packets that are part of 874 transport-level connections that the mobile node may still be 875 using after moving to a new location, the mobile node should use 876 its home address in this way. If a binding exists, the mobile 877 node should send the packets directly to the correspondent node. 878 Otherwise if a binding does not exist, the mobile node must use 879 reverse tunnelling. 881 o The mobile node may choose to directly use one of its care-of 882 addresses as the source of the packet, not requiring the use of a 883 home address option in the packet. This is particularly useful 884 for short-term communication that may easily be retried if it 885 fails. Using the mobile node's care-of address as the source for 886 such queries will generally have a lower overhead than using the 887 mobile node's home address, since no extra options need to be used 888 in either the query or its reply. Such packets can be routed 889 normally, directly between their source and destination without 890 relying on Mobile IPv6. If an application running on the mobile 891 node has no particular knowledge that the communication being sent 892 fits within this general type of communication, however, the 893 mobile node should not use its care-of address as the source of 894 the packet in this way. The choice of the most efficient 895 communications method id application specific. 897 o While not at its home link, the mobile node must not use the home 898 address destination option when communication with link-local 899 peers. Similarly the mobile node must not use the home address 900 destination option for IPv6 Neighbour discovery packets. 902 2.5.1. Crime Attribution Characteristics 904 As mentioned above, care-of addresses can be generated using normal 905 IPv6 mechanisms such as stateless or stateful autoconfiguration and 906 will presumably be assigned in accordance with the configuration of 907 the "care-of" network to which the node is connected. 909 Three issues related to crime attribution have been identified 910 regarding the use of Mobile IPv6. These will be discussed in the 911 following sections. 913 2.5.1.1. Attribution of the activity of the mobile node from 914 information available at the home network 916 Consider a node whose home network is "A", with a home IPv6 address 917 of "A1" is present on a network "B" using care-of address "B1". 919 To allow forwarding of traffic to A1 while it is on network B, the 920 node will register the binding between its home address and its care- 921 of address with the home agent on network "A". This registration 922 could, in principle at least, be recorded and made available if 923 needed for a criminal investigation. Therefore, the best attribution 924 information is likely to be available in the records of the home 925 network, presuming those records are retained. 927 It is possible that an administrator of the home network could 928 determine the preferred "care-of" address of a particular IPv6 929 address from records generated from the normal operation of the 930 Mobile IPv6 protocol. 932 However, this presumes that a law enforcement agency knows to request 933 information about the activity of IP address A1. It is possible that 934 the mobile node may choose to use the care-of address (B1 in this 935 example) as the source IP address in IP packets while away from home. 936 In these cases, it is not clear how a law enforcement agency would 937 even know about the relationship between the node and network A at 938 all. To make that link feasible requires that network "B" has 939 retained records of devices to which care-of addresses have been 940 assigned and this will be discussed in the next section. 942 2.5.1.2. Attribution of the activity of the mobile node from 943 information available at the care-of network 945 The mobile node has been assigned an IP address on the network B and, 946 in the first instance, all of the attribution issues discussed 947 elsewhere in this document will be applicable to the care-of address 948 of the mobile node. 950 It is not apparent from the protocol that there is any difference 951 between assignment of an IPv6 address to a mobile node that is 952 visiting the network as opposed to assignment of an IPv6 address to a 953 node for which it is the home network. If there is any difference, 954 it would appear that the differences are organisational, meaning that 955 addresses for mobile nodes are assigned from a different portion of 956 the organisation's address space or are more comprehensively 957 monitored, for example. There is, however, no particular reason 958 (from the point of view of the Mobile IPv6 protocol) why temporary 959 SLAAC addresses or other addresses for which no attribution records 960 are retained, could not be assigned as care-of addresses to mobile 961 nodes. 963 The protocol allows a mobile node to select its care-of address as 964 the source address in IP packets and if this communication is 965 criminal in nature, the records of which node was using the care-of 966 address at a particular point in time would become important. 968 There is no aspect of the protocol that requires the "care-of" 969 network to retain any particular records of use by mobile nodes of 970 care-of addresses, or to retain any record of the binding between 971 care-of addresses and home addresses. The hope, therefore, is that 972 organisations that assign care-of addresses keep records of 973 assignments on their network. 975 In summary, it may be very challenging for law enforcement 976 authorities to identify the home network of a particular node based 977 only on the care-of address and records available at the "care-of" 978 network. 980 2.5.1.3. The ephemeral nature of correspondent routing/route 981 optimisation information 983 Correspondent routing/route optimisation allows a correspondent node 984 to cache an association between the home and care-of addresses of the 985 mobile node, and forward traffic directly to the mobile node rather 986 than tunnel that traffic via the home agent. For the purpose of this 987 discussion, consider the mobile node as engaging in criminal activity 988 with the correspondent node being the victim or source of evidence of 989 the activity. 991 In this case, because the route optimisation is only temporarily 992 cached, it is highly likely that after a period of time the 993 correspondent node will not retain any record of the relationship 994 between the care-of and home addresses of the mobile node. The only 995 remaining record will be of the activity of the care-of address, 996 meaning total reliance of the records of the "care-of" network to 997 associate the care-of address with the home address of the mobile 998 node. 1000 2.6. IPv6 Address Selection 1002 IPv6 allows multiple unicast addresses to be assigned to interfaces. 1003 These addresses might have different reachability scopes (link-local, 1004 site-local or global). They might also be preferred or deprecated. 1005 There might also be public addresses and temporary addresses. Both 1006 the source and destination endpoints may have multiple IP addresses 1007 by which they can communicate with each other. 1009 [RFC6724] describes two related algorithms, one for source address 1010 selection and one for destination address selection that can be used 1011 by hosts when selecting IP addresses from the range of possibilities. 1012 The document specifies default behaviour and does not override 1013 choices made by applications or upper-layer protocols, nor does it 1014 preclude the development of more advanced mechanisms for address 1015 selection. In dual stack implementations, the destination address 1016 selection algorithm can consider both IPv4 and IPv6 addresses, 1017 depending on the available source addresses. 1019 The algorithm uses several criteria in making decisions. The 1020 combined effect is to prefer destination/source address pairs for 1021 which the two addresses are of equal scope or type, prefer smaller 1022 scopes over larger scopes for the destination address, prefer non- 1023 deprecated source addresses, avoid the use of transitional addresses 1024 when native addresses are available and all else being equal prefer 1025 address pairs having the longest possible common prefix. For source 1026 address selection, temporary addresses are preferred over public 1027 addresses. In mobile situations, home addresses are preferred over 1028 care-of addresses. 1030 The default address selection document also mandates implementations 1031 to provide a mechanism that allows an application to configure its 1032 preference for temporary addresses over public addresses. It also 1033 allows for an implementation to prefer temporary addresses by 1034 default, so that the connections initiated by the node can use 1035 temporary addresses without requiring application-specific 1036 enablement. 1038 2.6.1. Crime Attribution Characteristics 1040 The preference for temporary source addresses is explicitly 1041 incorporated into the default IPv6 address selection algorithms 1042 outlined in [RFC6724]. 1044 This recommendation further exacerbates the challenges highlighted in 1045 Section 2.3.2 relating to the use of temporary addresses and 1046 increases the importance of addressing these issues. 1048 2.7. IPv6 Edge Router Recommendations 1050 [RFC7084] specifies requirements for an IPv6 Customer Edge (CE) 1051 router. Specifically, the document focuses on the basic provisioning 1052 of an IPv6 CE router and the provisioning of IPv6 hosts attached to 1053 it. The document also covers IP transition technologies. 1055 This document specifies, amongst other things, how an IPv6 CE router 1056 automatically provisions its WAN interface, acquires address space 1057 for provisioning of its LAN interfaces, and fetches other 1058 configuration information from the service provider network. 1059 Automatic provisioning of more complex topology than a single router 1060 with multiple LAN interfaces is out of scope for the document. 1062 It was noted that requirement L-8 is: 1064 An IPv6 CE router MUST support a DHCPv6 server capable of IPv6 1065 address assignment according to [RFC3315] OR a stateless DHCPv6 1066 server according to [RFC3736] on its LAN interfaces. 1068 [RFC6092] describes an additional set of recommended security 1069 capabilities for devices at the perimeter of local-area IPv6 networks 1070 in Internet-enabled homes and small offices. 1072 2.7.1. Crime Attribution Characteristics 1074 Requirement L-8, cited above indicates that the IPv6 CE router might 1075 be assigning addresses to endpoints. No corresponding recommendation 1076 that the router should record which addresses have been assigned to 1077 endpoints is contained in the document. No recommendation related to 1078 recording address assignments is contained in [RFC6092] either. 1080 2.8. IPv6 Prefix Per Host 1082 For reasons of improved host isolation and enhanced subscriber 1083 management on shared network segments, there are published approaches 1084 for assigning IPv6 prefixes to individual hosts [RFC8273], [RFC3314], 1085 [RFC7934]. Advantages are then achieved by making sure that devices 1086 cannot send packets to each other except through the first-hop 1087 router. 1089 2.8.1. Crime Attribution Characteristics 1091 2.8.1.1. Usage of endpoint addresses 1093 It is understood from the referenced sources that this model is 1094 proposed for use principally in mobile networks. The crime 1095 attribution characteristics of assignment of an IPv6 prefix per host 1096 will depend on the use to which the host puts the prefix. For 1097 example, in the scenario where a mobile device is acting as a 1098 "hotspot" for other tethered devices it will no longer be possible to 1099 attribute all activity related to any addresses with the prefix to a 1100 specific endpoint. This scenario is specifically discussed in 1101 [RFC3314] and [RFC7934] as an advantage of assigning IPv6 prefixes 1102 per host. 1104 This situation is analogous to the situation with attributing 1105 criminal activity to a host that is attached to a wireless LAN access 1106 point. Without appropriate security controls there is a risk that an 1107 attacker could use an unauthorised connection to the wireless LAN 1108 access point to commit criminal acts. Similarly in cases where an 1109 IPv6 prefix has been assigned to a mobile device that can act as a 1110 wireless "hotspot", unauthorised tethered devices may be able to 1111 perform criminal acts in an untraceable way. This problem is, of 1112 course, not specific to IPv6 because the same problem could arise 1113 with an unauthorised tethering to a mobile device using IPv4. 1115 2.8.1.2. Frequently changing prefixes 1117 It has been highlighted elsewhere that the assignment of a prefix per 1118 host could make the prefix an identifying characteristic of the host, 1119 with the associated privacy implications 1120 [I-D.herbert-ipv6-prefix-address-privacy]. The reference cited 1121 proposes a high-level model involving the randomisation of addresses 1122 to address this (referred to as identifier addresses), followed by an 1123 address translation to a globally stable addresses (referred to as 1124 locator addresses). The document proposes that the crime attribution 1125 concerns of the proposed approach could be addressed by maintaining 1126 records of the mappings between identifier and locator addresses, 1127 meaning that from a crime attribution point of view the proposed 1128 technology would be similar to an IPv4 NAT. 1130 3. Conclusion 1132 Significant consideration has been given to the privacy and security 1133 considerations of IPv6 assignment methodologies and supporting 1134 technologies. 1136 However, inasmuch as IPv6 is intended to address the shortcomings of 1137 IPv4, the shortcomings related to crime attribution do not appear to 1138 have received sufficient consideration. In fact, the trajectory of 1139 the work reviewed during the production of this document would seem 1140 to indicate a significantly greater focus on architectural models to 1141 actively obfuscate the identity of endpoints using IPv6. 1143 Whilst individual privacy is extremely important, total privacy would 1144 have significant negative implications for law enforcement ability to 1145 conduct investigations of criminal activity online as well as on the 1146 rights of victims of crime. 1148 It is hoped that the production of this document will stimulate 1149 further discussion on the matter. 1151 4. IANA Considerations 1153 This memo includes no request to IANA. 1155 5. Security Considerations 1157 Many of the cited documents contain security considerations for the 1158 technologies that they define or consider and from a technical 1159 perspective, this document does not introduce any additional security 1160 considerations. 1162 On the other hand, this document considers the security features of 1163 those same technologies from a different perspective and in that 1164 respect, this entire document is a consideration of security 1165 implications of those technologies. 1167 6. References 1169 6.1. Informative References 1171 [I-D.daveor-cgn-logging] 1172 O'Reilly, D., "Approaches to Address the Availability of 1173 Information in Criminal Investigations Involving Large- 1174 Scale IP Address Sharing Technologies", draft-daveor-cgn- 1175 logging-04 (work in progress), April 2018. 1177 [I-D.herbert-ipv6-prefix-address-privacy] 1178 Herbert, T., "Privacy in IPv6 Network Prefix Assignment", 1179 draft-herbert-ipv6-prefix-address-privacy-00 (work in 1180 progress), February 2018. 1182 6.2. Normative References 1184 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 1185 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 1186 . 1188 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 1189 IPv6 Packets over Token Ring Networks", RFC 2470, 1190 DOI 10.17487/RFC2470, December 1998, 1191 . 1193 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1194 over Non-Broadcast Multiple Access (NBMA) networks", 1195 RFC 2491, DOI 10.17487/RFC2491, January 1999, 1196 . 1198 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 1199 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 1200 . 1202 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 1203 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 1204 . 1206 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 1207 Domains without Explicit Tunnels", RFC 2529, 1208 DOI 10.17487/RFC2529, March 1999, 1209 . 1211 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 1212 IPv6 Packets over Frame Relay Networks Specification", 1213 RFC 2590, DOI 10.17487/RFC2590, May 1999, 1214 . 1216 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1217 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1218 2001, . 1220 [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport 1221 Relay Translator", RFC 3142, DOI 10.17487/RFC3142, June 1222 2001, . 1224 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 1225 DOI 10.17487/RFC3164, August 2001, 1226 . 1228 [RFC3314] Wasserman, M., Ed., "Recommendations for IPv6 in Third 1229 Generation Partnership Project (3GPP) Standards", 1230 RFC 3314, DOI 10.17487/RFC3314, September 2002, 1231 . 1233 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1234 C., and M. Carney, "Dynamic Host Configuration Protocol 1235 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1236 2003, . 1238 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 1239 "Link Selection sub-option for the Relay Agent Information 1240 Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 1241 2003, . 1243 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 1244 (DHCP) Service for IPv6", RFC 3736, DOI 10.17487/RFC3736, 1245 April 2004, . 1247 [RFC3964] Savola, P. and C. Patel, "Security Considerations for 1248 6to4", RFC 3964, DOI 10.17487/RFC3964, December 2004, 1249 . 1251 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1252 RFC 3972, DOI 10.17487/RFC3972, March 2005, 1253 . 1255 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1256 for IPv6 Hosts and Routers", RFC 4213, 1257 DOI 10.17487/RFC4213, October 2005, 1258 . 1260 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1261 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1262 2006, . 1264 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 1265 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 1266 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 1267 January 2006, . 1269 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1270 Network Address Translations (NATs)", RFC 4380, 1271 DOI 10.17487/RFC4380, February 2006, 1272 . 1274 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 1275 InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 1276 2006, . 1278 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1279 Address Autoconfiguration", RFC 4862, 1280 DOI 10.17487/RFC4862, September 2007, 1281 . 1283 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 1284 Extensions for Stateless Address Autoconfiguration in 1285 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 1286 . 1288 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 1289 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 1290 . 1292 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 1293 Madanapalli, "Transmission of IPv6 via the IPv6 1294 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 1295 DOI 10.17487/RFC5121, February 2008, 1296 . 1298 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 1299 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 1300 DOI 10.17487/RFC5214, March 2008, 1301 . 1303 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 1304 Infrastructures (6rd)", RFC 5569, DOI 10.17487/RFC5569, 1305 January 2010, . 1307 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 1308 Infrastructures (6rd) -- Protocol Specification", 1309 RFC 5969, DOI 10.17487/RFC5969, August 2010, 1310 . 1312 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 1313 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 1314 DOI 10.17487/RFC6052, October 2010, 1315 . 1317 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 1318 Capabilities in Customer Premises Equipment (CPE) for 1319 Providing Residential IPv6 Internet Service", RFC 6092, 1320 DOI 10.17487/RFC6092, January 2011, 1321 . 1323 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1324 NAT64: Network Address and Protocol Translation from IPv6 1325 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 1326 April 2011, . 1328 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 1329 Assignment to End Sites", BCP 157, RFC 6177, 1330 DOI 10.17487/RFC6177, March 2011, 1331 . 1333 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 1334 China Education and Research Network (CERNET) IVI 1335 Translation Design and Deployment for the IPv4/IPv6 1336 Coexistence and Transition", RFC 6219, 1337 DOI 10.17487/RFC6219, May 2011, 1338 . 1340 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 1341 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 1342 2011, . 1344 [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, 1345 "Logging Recommendations for Internet-Facing Servers", 1346 BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011, 1347 . 1349 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1350 Stack Lite Broadband Deployments Following IPv4 1351 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 1352 . 1354 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1355 "Default Address Selection for Internet Protocol Version 6 1356 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 1357 . 1359 [RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. 1360 Huston, "Stateless Source Address Mapping for ICMPv6 1361 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, 1362 . 1364 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 1365 Combination of Stateful and Stateless Translation", 1366 RFC 6877, DOI 10.17487/RFC6877, April 2013, 1367 . 1369 [RFC7040] Cui, Y., Wu, J., Wu, P., Vautrin, O., and Y. Lee, "Public 1370 IPv4-over-IPv6 Access Network", RFC 7040, 1371 DOI 10.17487/RFC7040, November 2013, 1372 . 1374 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 1375 Requirements for IPv6 Customer Edge Routers", RFC 7084, 1376 DOI 10.17487/RFC7084, November 2013, 1377 . 1379 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 1380 Interface Identifiers with IPv6 Stateless Address 1381 Autoconfiguration (SLAAC)", RFC 7217, 1382 DOI 10.17487/RFC7217, April 2014, 1383 . 1385 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 1386 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 1387 Transport Profile (MPLS-TP) Linear Protection to Match the 1388 Operational Expectations of Synchronous Digital Hierarchy, 1389 Optical Transport Network, and Ethernet Transport Network 1390 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 1391 . 1393 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 1394 Farrer, "Lightweight 4over6: An Extension to the Dual- 1395 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 1396 July 2015, . 1398 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 1399 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 1400 Port with Encapsulation (MAP-E)", RFC 7597, 1401 DOI 10.17487/RFC7597, July 2015, 1402 . 1404 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 1405 and T. Murakami, "Mapping of Address and Port using 1406 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 1407 2015, . 1409 [RFC7600] Despres, R., Jiang, S., Ed., Penno, R., Lee, Y., Chen, G., 1410 and M. Chen, "IPv4 Residual Deployment via IPv6 - A 1411 Stateless Solution (4rd)", RFC 7600, DOI 10.17487/RFC7600, 1412 July 2015, . 1414 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 1415 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, 1416 . 1418 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 1419 Considerations for IPv6 Address Generation Mechanisms", 1420 RFC 7721, DOI 10.17487/RFC7721, March 2016, 1421 . 1423 [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address 1424 Mappings for Stateless IP/ICMP Translation", RFC 7757, 1425 DOI 10.17487/RFC7757, February 2016, 1426 . 1428 [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, 1429 "IP/ICMP Translation Algorithm", RFC 7915, 1430 DOI 10.17487/RFC7915, June 2016, 1431 . 1433 [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, 1434 "Host Address Availability Recommendations", BCP 204, 1435 RFC 7934, DOI 10.17487/RFC7934, July 2016, 1436 . 1438 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 1439 "Recommendation on Stable IPv6 Interface Identifiers", 1440 RFC 8064, DOI 10.17487/RFC8064, February 2017, 1441 . 1443 [RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix 1444 per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017, 1445 . 1447 [RIPE_699] 1448 RIPE, "IPv6 Address Allocation and Assignment Policy", 1449 2016, . 1451 Author's Address 1453 David O'Reilly 1454 Ireland 1456 Email: rfc@daveor.com