idnits 2.17.1 draft-daveor-slaac-privacy-logging-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 27, 2018) is 2161 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 4941 (Obsoleted by RFC 8981) Summary: 2 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 May 27, 2018 4 Intended status: Informational 5 Expires: November 28, 2018 7 A Model for Storing IPv6 Stateless Address Autoconfiguration Crime 8 Attribution Records in a Privacy Sensitive Way 9 draft-daveor-slaac-privacy-logging-00 11 Abstract 13 The need for individual right to privacy and the need for law 14 enforcement to be able to effectively investigate crime are sometimes 15 portrayed as being irreconcilably in direct conflict with each other. 16 Both needs are legitimate and ignoring the challenges presented by 17 areas of conflict will not make the problem go away. 19 The document presents a conceptual model that allows for both sets of 20 requirements to be met simultaneously. The reason for this 21 publication is to show that, with some creative thinking, it is 22 possible to identify win-win solutions that simultaneously achieve 23 both privacy and law enforcement goals. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 28, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. SLAAC: Stateless Address Autoconfiguration . . . . . . . 3 61 1.1.1. Stable Address Autoconfiguration . . . . . . . . . . 4 62 1.1.2. Temporary Address Autoconfiguration . . . . . . . . . 5 63 1.1.3. Crime Attribution Characteristics . . . . . . . . . . 7 64 1.1.3.1. Stateless Address Autoconfiguration . . . . . . . 7 65 1.1.3.2. SLAAC with stable interface identifiers . . . . . 8 66 1.1.3.3. SLAAC with temporary interface identifiers . . . 8 67 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Record Generation . . . . . . . . . . . . . . . . . . . . 9 71 3.3. Record Transmission and Storage . . . . . . . . . . . . . 10 72 3.4. Record Querying . . . . . . . . . . . . . . . . . . . . . 11 73 4. Proof of Concept . . . . . . . . . . . . . . . . . . . . . . 12 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 6.1. Cryptographic Strength . . . . . . . . . . . . . . . . . 12 77 6.2. Injection of False Records . . . . . . . . . . . . . . . 13 78 6.3. Retention Period of Records . . . . . . . . . . . . . . . 13 79 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 13 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 IPv6 addresses are assigned to organisations in blocks that are much 86 larger than the size of the blocks in which IPv4 addresses are 87 assigned, with common IPv6 prefix sizes being /48, /56 and /64 88 [RFC6177], [RIPE_699]. Current regulatory models typically oblige 89 ISPs to keep records to facilitate identification of their 90 subscribers, and in the case of IPv6 this will mean recording the 91 prefix(es) have been assigned to each customer. 93 From the perspective of crime attribution, therefore, when a specific 94 IP address is suspected to be associated with criminal activity, 95 records will most likely available from an ISP to identify the 96 organisation to which the prefix has been assigned. The question 97 then arises how an organisation approached by law enforcement 98 authorities, particularly a large organisation, would be able to 99 ascertain which host/endpoint within their network was using a 100 particular IP address at a particular time. 102 This is not a new problem, with many difficulties of crime 103 attribution already present in the IPv4 Internet. Nevertheless, it 104 is worthwhile to consider the crime attribution characteristics of 105 IPv6 in anticipation of wider deployment of this technology in the 106 coming years. 108 IPv6 provides several mechanisms through which hosts can be assigned 109 an IP address. [RFC7721] provides a list of these. Briefly they can 110 be summarised as: 112 o Manually configured addresses 114 o DHCPv6 assigned addresses 116 o Stateless Address Autoconfiguration (SLAAC) 118 o Addresses derived from an IPv4 address (transitional) 120 When approached by a law enforcement agency to identify the host/ 121 endpoint that was using a particular IP address at a particular time, 122 the organisation's ability to deliver this information will depend on 123 how IPv6 addresses are being assigned to endpoints within their 124 network. 126 1.1. SLAAC: Stateless Address Autoconfiguration 128 IPv6 Stateless Address Autoconfiguration (SLAAC) describes the 129 process used by a host in deciding how to auto configure its 130 interfaces in IPv6[RFC4862]. This includes generating a link-local 131 address, generating global addresses via stateless address 132 autoconfiguration and then using duplicate address detection to 133 verify the uniqueness of the addresses on the link. SLAAC requires 134 no manual configuration of hosts, minimal (if any) configuration of 135 routers, and no additional servers. 137 Routers advertise prefixes that identify the subnet(s) associated 138 with a link and hosts generate an interface identifier that uniquely 139 identifies an interface on a subnet. An address is formed by 140 combining these two. In the absence of a router, hosts generate only 141 link-local addresses. Autoconfiguration is only possible on 142 multicast-capable links. 144 The process begins by generating a link-local address for the 145 interface. This is achieved by appending the interface identifier to 146 the well-known link-local prefix. At this point, the address is 147 considered "tentative" because it might be in use by another host on 148 the network. The host verifies the uniqueness of the address by 149 sending a Neighbour Solicitation message containing the tentative 150 address. If the address is already in use, the node that is using 151 that address will send back a Neighbour Advertisement message. If 152 the address is not unique, auto configuration stops and manual 153 configuration is required or an alternative interface identifier can 154 be used, if one is configured. 156 Once it has been established that the link-local address is unique, 157 it is assigned to the interface. Next, the host listens for a Router 158 Advertisement message or, if the host does not want to wait, it can 159 send a Router Solicitation message to the all-routers multicast 160 group. 162 Router Advertisement messages contain zero or more prefix information 163 options that contain information that can be used to generate global 164 addresses. Hosts can use stateless address autoconfiguration and 165 DHCPv6 simultaneously if they want. If the Router Advertisement 166 indicates that the prefixes can be used for autoconfiguration (by 167 setting the "autonomous address-configuration flag" in the Prefix 168 Information option field) it will also include a subnet prefix and 169 lifetime values, indicating how long addresses created from this 170 prefix will remain preferred and valid. Hosts process all Router 171 Advertisements that are received periodically, adding to and 172 refreshing the information received in previous advertisements. 174 Crucial to the crime attribution properties of SLAAC is the selection 175 of interface identifier. Various algorithms exist for the generation 176 of interface identifiers, depending on whether the interface 177 identifier is intended to be stable (long-lived) or temporary. The 178 following two sub-sections describe stable and temporary interface 179 identifier generation algorithms. 181 1.1.1. Stable Address Autoconfiguration 183 Originally, various standards specified that the interface identifier 184 should be generated from the link-layer address of the interface. 185 For example [RFC2467], [RFC2470], [RFC2491], [RFC2492], [RFC2497], 186 [RFC2590], [RFC3164], [RFC3527], [RFC4338], [RFC4391], [RFC5072], 187 [RFC5121]. This is used in cases where a stable IPv6 address is 188 being generated. 190 [RFC8064] changes the recommended default interface identifier 191 generation scheme when SLAAC is in use to generate stable IPv6 192 addresses. It recommends against embedding stable link-layer 193 addresses in IPv6 interface identifiers, recommending instead the use 194 of a semantically opaque value as defined in [RFC7217] over all other 195 alternatives. [RFC8064] also highlights some reasons why a stable 196 IPv6 address would be desirable. For example, network management, 197 event logging, enforcement of access control, provision of quality of 198 service or for server or router interfaces. Similarly, they allow 199 long-lived TCP connections. However, the document does not make 200 recommendations about WHEN stable addresses should be used and when 201 temporary addresses should be used. 203 [RFC7271] describes a method where an IPv6 address can be configured 204 in such a way that it is stable within each subnet but the interface 205 identifier changes when the host moves from one network to another. 206 In general terms, the approach is to pass the following values to a 207 cryptographic hash function (such as SHA1 or SHA256): 209 o The network prefix 211 o The network interface id 213 o The network id (subnet, SSID or similar) - optional parameter 215 o A duplicate address detection counter - incremented in case of a 216 duplicate address being generated 218 o A secret key (128 bits long at least) 220 The interface identifier is generated by taking as many bits, 221 starting at the least significant, as required. The result is an 222 opaque bit stream that can be used as the interface id. 224 1.1.2. Temporary Address Autoconfiguration 226 [RFC4941] describes a system by which interface identifiers generated 227 from an IEEE identifier (EUI-64) can be changed over time, even in 228 cases where the interface contains an embedded IEEE identifier. 229 These are referred to as temporary addresses. 231 The reason behind development of this technique is that the use of a 232 globally unique, non-changing, interface identifier means that the 233 activity of a specific interface can be tracked even if the network 234 prefix changes. The use of a fixed identifier in multiple contexts 235 allows correlation of seemingly unrelated activity using the 236 identifier. Contrast this with IPv4 addresses, where if a person 237 changes to a different network their entire IP address will change. 239 The goals of the temporary address generation procedure are that: 241 o Temporary address generation does not result in any changes to the 242 basic behaviour of addresses generated via SLAAC. 244 o The temporary address generation algorithm creates additional 245 addresses based on a random interface identifier for the purpose 246 of initiating outgoing sessions. These temporary addresses would 247 be used for a short period of time (hours to days) and would then 248 be deprecated. 250 o The algorithm produces a sequence of temporary global scope 251 addresses from the sequence of interface identifiers that appear 252 to be random in the sense that it is difficult for an outside 253 observer to predict a future address (or identifier) based on the 254 current one, or to determine a previous address (or identifier) 255 knowing only the current one. 257 o By default, the algorithm generates a set of addresses from the 258 same interface identifier, one for each prefix for which a global 259 address has been generated via SLAAC. Using the same interface 260 identifier to generate a set of temporary addresses reduces the 261 number of IP multicast groups that a host must join. 263 o A node highly concerned about privacy may use different 264 identifiers for different prefixes, resulting in a set of global 265 addresses that cannot be easily tied to each other. 267 To prevent the generation of predictable values, the algorithm must 268 contain an unpredictable component. The algorithm assumes that each 269 interface maintains an associated randomised interface identifier. 270 When temporary addresses are generated, the current value of the 271 interface identifier is used. The algorithm also assumes that for a 272 given temporary address, the implementation can determine the prefix 273 from which it was generated. 275 Two approaches to generate random interface identifiers are presented 276 in [RFC4941], depending on whether stable storage is present. 278 When stable storage is present, it is assumed that a 64-bit history 279 value is available and can be used. This value is generated as 280 described below. The first time the system boots, a random value is 281 selected. 283 1. Take the history value and append it to the interface identifier 284 generated as described in [RFC4291]. 286 2. Compute the MD5 of the resulting value 287 3. Take the leftmost 64 bits and set bit 6 to zero. (This creates 288 an interface identifier with the universal/local bit indicating 289 local significance only) 291 4. Compare the generated identifier against a list of reserved 292 identifiers and to those already assigned to an address on the 293 local device. If an unacceptable value has been generated, start 294 again at step 1. 296 5. Save the generated identifier. 298 6. Take the rightmost 64 bits and save them to state storage as the 299 history value for the next iteration of the algorithm. 301 When stable storage is not present, no history value will be 302 available. Therefore, the initial history value should be generated 303 at random. Algorithms other than MD5 can be used to compute the 304 temporary address if desired. 306 Other approaches such as cryptographically generated addresses (CGA) 307 can be used to generate random interface identifiers based on the 308 public key of the node [RFC3972]. The goal of CGAs is to prove 309 ownership of an address and prevent spoofing and stealing of IPv6 310 addresses. The CGA process may not be suitable for privacy addresses 311 because (a) it requires nodes to have a public key, meaning the node 312 can be identified by the key and (b) it is computationally intensive, 313 discouraging frequent regeneration. 315 Devices implementing this specification must provide a way for end 316 users to explicitly enable or disable the use of temporary addresses. 317 Also, sites might wish to disable it, so implementations should 318 provide a way for trusted system administrators to enable or disable 319 the use of temporary addresses. Implementations should also provide 320 a way to enable and disable generation of temporary addresses for 321 specific prefix subranges. 323 1.1.3. Crime Attribution Characteristics 325 1.1.3.1. Stateless Address Autoconfiguration 327 IPv6 addresses are assigned to organisations in blocks much larger 328 than the size of the blocks in which IPv4 addresses are assigned. 329 The question arises about how an organisation approached by law 330 enforcement authorities, particularly a large organisation, will be 331 able to ascertain which host/endpoint within their organisation was 332 using a particular IP address at a particular time when addresses 333 have been assigned using SLAAC. 335 From the crime attribution perspective, both the recommended stable 336 and temporary address generation algorithms pseudo-randomly select 337 addresses from the space of available addresses. When SLAAC is being 338 used, the hosts auto-configure the IP addresses of their interfaces, 339 meaning there is no organisational record of the IP addresses that 340 have been selected by particular hosts at particular points in time. 342 1.1.3.2. SLAAC with stable interface identifiers 344 From a crime attribution point of view, the use of a stable interface 345 identifier (whether generated for a link-local address or otherwise) 346 will provide some measure of assurance that it will be possible to 347 identify a specific host/interface based on the IPv6 address. While 348 it may not be possible for a network administrator to calculate the 349 interface identifier (and therefore the IPv6 address) that will be 350 used by a specific interface, due to the presence of a secret key, 351 with some effort it should be possible for a network operator to 352 determine which host/endpoint, or at least a relatively small subset 353 of hosts/endpoints, is responsible for traffic arising from a 354 particular IPv6 address. 356 Due to the relatively long-term use of a particular address by an 357 interface, it is at least possible that an organisation might be able 358 to use traffic flow analysis or other similar network monitoring 359 techniques to identify the endpoint using the address. This assumes 360 that the IPv6 address is still active and generating traffic. It 361 will also, of course, only identify the endpoint using the address at 362 the time of the traffic flow analysis and not at the time of the 363 alleged criminal activity that is under investigation. 365 1.1.3.3. SLAAC with temporary interface identifiers 367 The problem of crime attribution is exacerbated in the case of 368 temporary interface identifier generation due to the fact that the 369 generated addresses are the endpoint's preferred IPv6 address, by 370 default, for a period of one day [RFC4941]. 372 It is difficult to see how the activity of IPv6 addresses generated 373 using temporary interface identifiers could be attributed to any 374 host/endpoint. The interface identifier generation algorithm has a 375 cryptographic component, meaning that the addresses will appear to be 376 pseudo-randomly selected from the range of available addresses. 378 Even presuming that the host/endpoint is still active and generating 379 traffic there is no apparent way to associate the activity of the 380 host/endpoint's current address with the address in use at the time 381 of the alleged criminal activity. 383 This attribution problem is "by design", arising from the expected 384 behaviour of SLAAC with temporary interface identifiers. It 385 therefore seems that the crime attribution challenges that will arise 386 from the use of this technology have not been given due 387 consideration. The use of this technology will likely become a 388 significant crime attribution challenge in future. 390 2. Scope 392 This document presents a record-retention model whereby it is 393 possible for an organisation, if required to do so as part of a 394 criminal investigation, to answer the question "Who was using IP 395 address A at a particular point in time?" without being able to 396 answer any more broadly scoped questions, such as "What were all of 397 the IP addresses used by a particular person?" 399 3. Model 401 3.1. Assumptions 403 The model described here makes the following assumption: 405 o The endpoint/interface for which the IPv6 address is being 406 generated has a meaningful, unique identifying characteristic. 407 Whether that is the layer two address of the interface or some 408 other organisational characteristic is unimportant for the purpose 409 of the model. 411 3.2. Record Generation 413 The host generates a temporary IPv6 address using any of the 414 techniques described above, but most likely the technique described 415 in [RFC4941]. Having completed the duplicate address detection phase 416 of SLAAC, but before beginning to use the IP address for 417 communication, the host creates a structure of the following form: 419 typedef struct { 420 const char *LOG_ENTRY_TAG="__LOG_ENTRY_TAG__"; 421 unsigned char *ip_address; 422 unsigned int identifying_characteristic_length; 423 unsigned char *identifying_characteristic; 424 unsigned int client_generation_time; 425 unsigned int client_preferred_time; 426 unsigned int client_valid_time; 427 } log_entry; 429 The fields in the structure are all mandatory, and populated as 430 follows: 432 o LOG_ENTRY_TAG has the fixed, constant value "__LOG_ENTRY_TAG__" 434 o ip_address contains the 16 byte IPv6 address 436 o identifying_characteristic_length contains the byte length of the 437 identifying_characteristic field 439 o identifying_characteristic is a variable length byte string, 440 organisationally interpreted, to represent the identifying 441 characteristic of the host generating the IPv6 address 443 o client_generation_time contains the time, in seconds since the 444 unix epoch, as recorded by the client creating the IPv6 address, 445 at which the address was generated 447 o client_preferred_time contains the period, in seconds, starting at 448 client_generation_time for which the client will use this IPv6 449 address as its preferred address 451 o client_valid_time contains the period, in seconds, starting at 452 client_generation_time for which the client will consider this 453 IPv6 address to be valid 455 When the structure has been populated, the host encrypts the 456 structure using AES-128 in CBC mode with the selected IPv6 address 457 being used as the encryption key. 459 The record message is now ready for transmission. 461 3.3. Record Transmission and Storage 463 The host submits the completed record to a specified multicast 464 address and port but, when sending the record, sends it using the 465 unspecified IPv6 address (i.e. "::") as the source IP address. 467 When records are received by a logging server that is listening to 468 the specified multicast address, the logging server creates a new log 469 entry consisting of: 471 o The time the record was received, ideally calibrated to a global 472 standard time (e.g. NTP) with the granularity of a second. 474 o The received encrypted record as a binary blob. 476 3.4. Record Querying 478 If and when it becomes necessary to query the recorded entries, the 479 following (representative) process can be followed: 481 1. Taking the IP address for which the attribution information is 482 required, iterate through all recorded log entries and use the IP 483 address as a decryption key and attempt to decrypt the record. 485 2. Examine the decrypted data and check whether the first 17 bytes 486 have the values "__LOG_ENTRY_TAG__". 488 A. If so: 490 i This indicates that the log entry has been successfully 491 decrypted. 493 ii The IP address contained in the log entry can be verified 494 against the IP address that was used as a key to confirm 495 that the log entry contains the correct value. 497 iii The identifying characteristic can then be read from the 498 log entry, along with the time at which the host 499 generated the IP address. 501 iv The client_preferred_time and client_valid_time fields 502 can be used to check whether the IPv6 address was valid 503 and/or preferred by the client at the time of interest. 505 v The time in the record can be correlated with the time in 506 the log entry recorded by the server so that any time 507 differential can be compensated for. 509 B. If not: 511 i This indicates that the log entry has not been 512 successfully decrypted and that the current log entry 513 pertains to a different IP address. 515 ii Move on to the next log entry and try again. 517 As described in the next section, it would be computationally 518 feasible to use this process on a large number of log entries but, if 519 necessary, the space of log entries to be searched can be reduced by 520 selecting a range of log entries based on the time recorded by the 521 server. 523 4. Proof of Concept 525 A proof of concept implementation of the model above has been 526 developed. Log entries using pseudorandom IPv6 addresses were 527 generated for a network of 20,000 computers, changing IP address 528 every day (which is the default specified in [RFC4941]) for two 529 years. This leads to the generation of 14.6 million log entries. 531 Code was developed to select a random IP address, known to be 532 represented in the log entries, and search the entire log for entries 533 that are successfully decrypted using that IP address. This code was 534 executed 10,000 times and the following results were noted: 536 1. On a single CPU PC with an Intel Core i7 running at 2.8GHz it 537 takes on average 11.34 seconds (standard deviation 0.82 seconds) 538 to check the entire log. 540 2. In all 10,000 test cases, only a single log entry was 541 successfully decrypted - the one representing the attribution 542 data for the target IP address. 544 5. IANA Considerations 546 This memo includes no request to IANA. 548 6. Security Considerations 550 6.1. Cryptographic Strength 552 The strength of the key comes from the length and pseudo-random 553 nature of the IPv6 address generation mechanism, the very feature 554 that is desirable from a privacy perspective. 556 In order to decrypt a specific log entry without knowing the target 557 IP address, a brute force approach must be adopted. Presuming a 558 known 64-bit address prefix, means that there is a space of 2^64 559 possible addresses to search. 561 Code was also developed to attempt to brute force log entries, and it 562 was noted that on the same PC used for the testing above (single CPU 563 PC with an Intel Core i7 running at 2.8GHz) attempting to brute force 564 a single log entry would be computationally infeasible (approximately 565 22,313,257 years required). To decrypt the entire log would require 566 this same amount of time for each individual log entry. 568 6.2. Injection of False Records 570 In the model presented here, there is no mechanism to detect 571 injection of false records. A shared secret cryptographic model 572 could be developed but in order to maintain the privacy 573 characteristics of the concept, all authorised endpoints would need 574 to use the same shared secret otherwise it would be possible to a 575 rogue log recorder to reduce the range of possible hosts through 576 correlation of the encryption key. 578 6.3. Retention Period of Records 580 The period of time for which logs should be retained is, broadly 581 speaking, out of scope of this discussion. 583 Depending on national legislation there will be obligations on 584 certain types of organisations to retain logs for particular periods 585 of time. Most other organisations do not have any legal obligation 586 to retain records of which endpoint was using a specific IP address 587 at a particular point in time, although these records are often kept 588 for other reasons such as network security, performance monitoring 589 and troubleshooting. 591 7. Conclusion 593 The model presented here provides a balance between the needs for 594 individual privacy at the network layer while also providing a 595 mechanism for recording data that would be required in a criminal 596 investigation. The balance that has been proposed here is at the 597 point where it is possible to identify, using this technique, who was 598 using a specific IP address at a specific point in time without being 599 able to extract any more information such as all of the people who 600 were using a particular IP or all of the IP addresses that were used 601 by a particular endpoint. 603 8. Normative References 605 [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI 606 Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, 607 . 609 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of 610 IPv6 Packets over Token Ring Networks", RFC 2470, 611 DOI 10.17487/RFC2470, December 1998, 612 . 614 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 615 over Non-Broadcast Multiple Access (NBMA) networks", 616 RFC 2491, DOI 10.17487/RFC2491, January 1999, 617 . 619 [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM 620 Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, 621 . 623 [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet 624 Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, 625 . 627 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of 628 IPv6 Packets over Frame Relay Networks Specification", 629 RFC 2590, DOI 10.17487/RFC2590, May 1999, 630 . 632 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 633 DOI 10.17487/RFC3164, August 2001, 634 . 636 [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, 637 "Link Selection sub-option for the Relay Agent Information 638 Option for DHCPv4", RFC 3527, DOI 10.17487/RFC3527, April 639 2003, . 641 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 642 RFC 3972, DOI 10.17487/RFC3972, March 2005, 643 . 645 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 646 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 647 2006, . 649 [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of 650 IPv6, IPv4, and Address Resolution Protocol (ARP) Packets 651 over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, 652 January 2006, . 654 [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over 655 InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April 656 2006, . 658 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 659 Address Autoconfiguration", RFC 4862, 660 DOI 10.17487/RFC4862, September 2007, 661 . 663 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 664 Extensions for Stateless Address Autoconfiguration in 665 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 666 . 668 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 669 over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, 670 . 672 [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. 673 Madanapalli, "Transmission of IPv6 via the IPv6 674 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, 675 DOI 10.17487/RFC5121, February 2008, 676 . 678 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address 679 Assignment to End Sites", BCP 157, RFC 6177, 680 DOI 10.17487/RFC6177, March 2011, 681 . 683 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 684 Interface Identifiers with IPv6 Stateless Address 685 Autoconfiguration (SLAAC)", RFC 7217, 686 DOI 10.17487/RFC7217, April 2014, 687 . 689 [RFC7271] Ryoo, J., Ed., Gray, E., Ed., van Helvoort, H., 690 D'Alessandro, A., Cheung, T., and E. Osborne, "MPLS 691 Transport Profile (MPLS-TP) Linear Protection to Match the 692 Operational Expectations of Synchronous Digital Hierarchy, 693 Optical Transport Network, and Ethernet Transport Network 694 Operators", RFC 7271, DOI 10.17487/RFC7271, June 2014, 695 . 697 [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy 698 Considerations for IPv6 Address Generation Mechanisms", 699 RFC 7721, DOI 10.17487/RFC7721, March 2016, 700 . 702 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 703 "Recommendation on Stable IPv6 Interface Identifiers", 704 RFC 8064, DOI 10.17487/RFC8064, February 2017, 705 . 707 [RIPE_699] 708 RIPE, "IPv6 Address Allocation and Assignment Policy", 709 2016, . 711 Author's Address 713 David O'Reilly 714 Ireland 716 Email: rfc@daveor.com