1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) A. Cooper
Request for Comments: 7721 Cisco
Category: Informational F. Gont
ISSN: 2070-1721 Huawei Technologies
D. Thaler
Microsoft
March 2016
<span class="h1">Security and Privacy Considerations for</span>
<span class="h1">IPv6 Address Generation Mechanisms</span>
Abstract
This document discusses privacy and security considerations for
several IPv6 address generation mechanisms, both standardized and
non-standardized. It evaluates how different mechanisms mitigate
different threats and the trade-offs that implementors, developers,
and users face in choosing different addresses or address generation
mechanisms.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7721">http://www.rfc-editor.org/info/rfc7721</a>.
<span class="grey">Cooper, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. Weaknesses in IEEE-Identifier-Based IIDs . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Correlation of Activities over Time . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Location Tracking . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. Address Scanning . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Device-Specific Vulnerability Exploitation . . . . . . . <a href="#page-7">7</a>
4. Privacy and Security Properties of Address Generation
Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4.1">4.1</a>. IEEE-Identifier-Based IIDs . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.2">4.2</a>. Static, Manually Configured IIDs . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.3">4.3</a>. Constant, Semantically Opaque IIDs . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.4">4.4</a>. Cryptographically Generated IIDs . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4.5">4.5</a>. Stable, Semantically Opaque IIDs . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.6">4.6</a>. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.7">4.7</a>. DHCPv6 Generation of IIDs . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4.8">4.8</a>. Transition and Coexistence Technologies . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. Miscellaneous Issues with IPv6 Addressing . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.1">5.1</a>. Network Operation . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.2">5.2</a>. Compliance . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-5.3">5.3</a>. Intellectual Property Rights (IPRs) . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="grey">Cooper, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
IPv6 was designed to improve upon IPv4 in many respects, and
mechanisms for address assignment were one such area for improvement.
In addition to static address assignment and DHCP, stateless
autoconfiguration was developed as a less intensive, fate-shared
means of performing address assignment. With stateless
autoconfiguration, routers advertise on-link prefixes and hosts
generate their own Interface Identifiers (IIDs) to complete their
addresses. [<a href="./rfc7136" title=""Significance of IPv6 Interface Identifiers"">RFC7136</a>] clarifies that the IID should be treated as an
opaque value, while [<a href="./rfc7421" title=""Analysis of the 64-bit Boundary in IPv6 Addressing"">RFC7421</a>] provides an analysis of the 64-bit
boundary in IPv6 addressing (e.g., the implications of the IID length
on security and privacy). Over the years, many IID generation
techniques have been defined, both standardized and non-standardized:
o Manual configuration [<a href="./rfc7707" title=""Network Reconnaissance in IPv6 Networks"">RFC7707</a>]
* IPv4 address
* Service port
* Wordy
* Low-byte
o Stateless Address Autoconfiguration (SLAAC)
* IEEE 802 48-bit Media Access Control (MAC) or IEEE 64-bit
Extended Unique Identifier (EUI-64) [<a href="./rfc2464" title=""Transmission of IPv6 Packets over Ethernet Networks"">RFC2464</a>]
* Cryptographically generated [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>]
* Temporary (also known as "privacy addresses") [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>]
* Constant, semantically opaque (also known as "random")
[<a href="#ref-Microsoft">Microsoft</a>]
* Stable, semantically opaque [<a href="./rfc7217" title=""A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"">RFC7217</a>]
o DHCPv6 based [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>]
o Specified by transition/co-existence technologies
* Derived from an IPv4 address (e.g., [<a href="./rfc5214" title=""Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"">RFC5214</a>], [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>])
* Derived from an IPv4 address and port set ID (e.g., [<a href="./rfc7596" title=""Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture"">RFC7596</a>],
[<a href="./rfc7597" title=""Mapping of Address and Port with Encapsulation (MAP-E)"">RFC7597</a>], [<a href="./rfc7599" title=""Mapping of Address and Port using Translation (MAP-T)"">RFC7599</a>])
<span class="grey">Cooper, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
* Derived from an IPv4 address and port (e.g., [<a href="./rfc4380" title=""Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)"">RFC4380</a>])
Deriving the IID from a globally unique IEEE identifier [<a href="./rfc2464" title=""Transmission of IPv6 Packets over Ethernet Networks"">RFC2464</a>]
[<a href="./rfc4862" title=""IPv6 Stateless Address Autoconfiguration"">RFC4862</a>] was one of the earliest mechanisms developed (and
originally specified in [<a href="./rfc1971" title=""IPv6 Stateless Address Autoconfiguration"">RFC1971</a>] and [<a href="./rfc1972" title=""A Method for the Transmission of IPv6 Packets over Ethernet Networks"">RFC1972</a>]). A number of
privacy and security issues related to the IIDs derived from IEEE
identifiers were discovered after their standardization, and many of
the mechanisms developed later aimed to mitigate some or all of these
weaknesses. This document identifies four types of attacks against
IEEE-identifier-based IIDs and discusses how other existing
techniques for generating IIDs do or do not mitigate those attacks.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
This section clarifies the terminology used throughout this document.
Public address:
An address that has been published in a directory or other public
location, such as the DNS, a SIP proxy [<a href="./rfc3261" title=""SIP: Session Initiation Protocol"">RFC3261</a>], an application-
specific Distributed Hash Table (DHT), or a publicly available
URI. A host's public addresses are intended to be discoverable by
third parties.
Stable address:
An address that does not vary over time within the same IPv6 link.
Note that [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] refers to these as "public" addresses, but
"stable" is used here for reasons explained in <a href="#section-4">Section 4</a>.
Temporary address:
An address that varies over time within the same IPv6 link.
Constant IID:
An IPv6 interface identifier that is globally stable. That is,
the Interface ID will remain constant even if the node moves from
one IPv6 link to another.
Stable IID:
An IPv6 interface identifier that is stable within some specified
context. For example, an Interface ID can be globally stable
(constant) or could be stable per IPv6 link (meaning that the
Interface ID will remain unchanged as long as the node stays on
the same IPv6 link but may change when the node moves from one
IPv6 link to another).
Temporary IID:
An IPv6 interface identifier that varies over time.
<span class="grey">Cooper, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>]. These words take their normative meanings only when they
are presented in ALL UPPERCASE.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Weaknesses in IEEE-Identifier-Based IIDs</span>
There are a number of privacy and security implications that exist
for hosts that use IEEE-identifier-based IIDs. This section
discusses four generic attack types: correlation of activities over
time, location tracking, address scanning, and device-specific
vulnerability exploitation. The first three of these rely on the
attacker first gaining knowledge of the IID of the target host. This
could be achieved by a number of different entities: the operator of
a server to which the host connects, such as a web server or a peer-
to-peer server; an entity that connects to the same IPv6 link as the
target (such as a conference network or any public network); a
passive observer of traffic that the host broadcasts; or an entity
that is on path to the destinations with which the host communicates,
such as a network operator.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Correlation of Activities over Time</span>
As with other identifiers, an IPv6 address can be used to correlate
the activities of a host for at least as long as the lifetime of the
address. The correlation made possible by IEEE-identifier-based IIDs
is of particular concern since they last roughly for the lifetime of
a device's network interface, allowing correlation on the order of
years.
As [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] explains,
[t]he use of a non-changing interface identifier to form addresses
is a specific instance of the more general case where a constant
identifier is reused over an extended period of time and in
multiple independent activities. Anytime the same identifier is
used in multiple contexts, it becomes possible for that identifier
to be used to correlate seemingly unrelated activity. ... The use
of a constant identifier within an address is of special concern
because addresses are a fundamental requirement of communication
and cannot easily be hidden from eavesdroppers and other parties.
Even when higher layers encrypt their payloads, addresses in
packet headers appear in the clear.
IP addresses are just one example of information that can be used to
correlate activities over time. DNS names, cookies [<a href="./rfc6265" title=""HTTP State Management Mechanism"">RFC6265</a>],
browser fingerprints [<a href="#ref-Panopticlick">Panopticlick</a>], and application-layer usernames
<span class="grey">Cooper, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
can all be used to link a host's activities together. Although IEEE-
identifier-based IIDs are likely to last at least as long or longer
than these other identifiers, IIDs generated in other ways may have
shorter or longer lifetimes than these identifiers depending on how
they are generated. Therefore, the extent to which a host's
activities can be correlated depends on whether the host uses
multiple identifiers together and the lifetimes of all of those
identifiers. Frequently refreshing an IPv6 address may not mitigate
correlation if an attacker has access to other longer-lived
identifiers for a particular host. This is an important caveat to
keep in mind throughout the discussion of correlation in this
document. For further discussion of correlation, see <a href="./rfc6973#section-5.2.1">Section 5.2.1
of [RFC6973]</a>.
As noted in [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>], in some cases correlation is just as feasible
for a host using an IPv4 address as for a host using an IEEE
identifier to generate its IID in its IPv6 address. Hosts that use
static IPv4 addressing or who are consistently allocated the same
address via DHCPv4 can be tracked as described above. However, the
widespread use of both NAT and DHCPv4 implementations that assign the
same host a different address upon lease expiration mitigates this
threat in the IPv4 case as compared to the IEEE identifier case in
IPv6.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Location Tracking</span>
Because the IPv6 address structure is divided between a topological
portion and an interface identifier portion, an interface identifier
that remains constant when a host connects to different IPv6 links
(as an IEEE-identifier-based IID does) provides a way for observers
to track the movements of that host. In a passive attack on a mobile
host, a server that receives connections from the same host over time
would be able to determine the host's movements as its prefix
changes.
Active attacks are also possible. An attacker that first learns the
host's interface identifier by being connected to the same IPv6 link,
running a server that the host connects to, or being on path to the
host's communications could subsequently probe other networks for the
presence of the same interface identifier by sending a probe packet
(e.g., ICMPv6 Echo Request, or any other probe packet). Even if the
host does not respond, the first-hop router will usually respond with
an ICMP Destination Unreachable/Address Unreachable (type 1, code 3)
when the host is not present and be silent when the host is present.
Location tracking based on IP address is generally not possible in
IPv4 since hosts get assigned wholly new addresses when they change
networks.
<span class="grey">Cooper, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Address Scanning</span>
The structure of IEEE-based identifiers used for address generation
can be leveraged by an attacker to reduce the target search space
[<a href="./rfc7707" title=""Network Reconnaissance in IPv6 Networks"">RFC7707</a>]. The 24-bit Organizationally Unique Identifier (OUI) of
MAC addresses, together with the fixed value (0xff, 0xfe) used to
form a Modified EUI-64 interface identifier, greatly help to reduce
the search space, making it easier for an attacker to scan for
individual addresses using widely known popular OUIs. This erases
much of the protection against address scanning that the larger IPv6
address space could provide as compared to IPv4.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Device-Specific Vulnerability Exploitation</span>
IPv6 addresses that embed IEEE identifiers leak information about the
device (e.g., Network Interface Card vendor, or even Operating System
and/or software type), which could be leveraged by an attacker with
knowledge of device- or software-specific vulnerabilities to quickly
find possible targets. Attackers can exploit vulnerabilities in
hosts whose IIDs they have previously obtained or scan an address
space to find potential targets.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Privacy and Security Properties of Address Generation Mechanisms</span>
Analysis of the extent to which a particular host is protected
against the attacks described in <a href="#section-3">Section 3</a> depends on how each of a
host's addresses is generated and used. In some scenarios, a host
configures a single global address and uses it for all
communications. In other scenarios, a host configures multiple
addresses using different mechanisms and may use any or all of them.
[<a id="ref-RFC3041">RFC3041</a>] (later obsoleted by [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>]) sought to address some of
the problems described in <a href="#section-3">Section 3</a> by defining "temporary addresses"
for outbound connections. Temporary addresses are meant to
supplement the other addresses that a device might use, not to
replace them. They use IIDs that are randomly generated and change
daily by default. The idea was for temporary addresses to be used
for outgoing connections (e.g., web browsing) while maintaining the
ability to use a stable address when more address stability is
desired (e.g., for IPv6 addresses published in the DNS).
[<a id="ref-RFC3484">RFC3484</a>] originally specified that stable addresses be used for
outbound connections unless an application explicitly prefers
temporary addresses. The default preference for stable addresses was
established to avoid applications potentially failing due to the
short lifetime of temporary addresses or the possibility of a reverse
look-up failure or error. However, [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>] allowed that
"implementations for which privacy considerations outweigh these
<span class="grey">Cooper, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
application-compatibility concerns MAY reverse the sense of this
rule" and instead prefer by default temporary addresses rather than
stable addresses. Indeed, most implementations (notably including
Windows) chose to default to temporary addresses for outbound
connections since privacy was considered more important (and few
applications supported IPv6 at the time, so application compatibility
concerns were minimal). [<a href="./rfc6724" title=""Default Address Selection for Internet Protocol Version 6 (IPv6)"">RFC6724</a>] then obsoleted [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>] and
changed the default to match what implementations actually did.
The envisioned relationship in [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>] between stability of an
address and its use in "public" can be misleading when conducting
privacy analysis. The stability of an address and the extent to
which it is linkable to some other public identifier are independent
of one another. For example, there is nothing that prevents a host
from publishing a temporary address in a public place, such as the
DNS. Publishing both a stable address and a temporary address in the
DNS or elsewhere where they can be linked together by a public
identifier allows the host's activities when using either address to
be correlated together.
Moreover, because temporary addresses were designed to supplement
other addresses generated by a host, the host may still configure a
more stable address even if it only ever intentionally uses temporary
addresses (as source addresses) for communication to off-link
destinations. An attacker can probe for the stable address even if
it is never used as such a source address or advertised outside the
link (e.g., in DNS or SIP).
This section compares the privacy and security properties of a
variety of IID generation mechanisms and their possible usage
scenarios, including scenarios in which a single mechanism is used to
generate all of a host's IIDs and those in which temporary addresses
are used together with addresses generated using a different IID
generation mechanism. The analysis of the exposure of each IID type
to correlation assumes that IPv6 prefixes are shared by a reasonably
large number of nodes. As [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] notes, if a very small number of
nodes (say, only one) use a particular prefix for an extended period
of time, the prefix itself can be used to correlate the host's
activities regardless of how the IID is generated. For example,
[<a href="./rfc3314" title=""Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards"">RFC3314</a>] recommends that prefixes be uniquely assigned to mobile
handsets where IPv6 is used within General Packet Radio Service
(GPRS). In cases where this advice is followed and prefixes persist
for extended periods of time (or get reassigned to the same handsets
whenever those handsets reconnect to the same network router), hosts'
activities could be correlatable for longer periods than the analysis
below would suggest.
<span class="grey">Cooper, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
The table below provides a summary of the whole analysis. A "No"
entry indicates that the attack is prevented from being carried out
on the basis of the IID, but the host may still be vulnerable
depending on how it employs other protocols.
+--------------+-------------+----------+-------------+-------------+
| Mechanism(s) | Correlation | Location | Address | Device |
| | | tracking | scanning | exploits |
+--------------+-------------+----------+-------------+-------------+
| IEEE | For device | For | Possible | Possible |
| identifier | lifetime | device | | |
| | | lifetime | | |
| | | | | |
| Static | For address | For | Depends on | Depends on |
| manual | lifetime | address | generation | generation |
| | | lifetime | mechanism | mechanism |
| | | | | |
| Constant, | For address | For | No | No |
| semantically | lifetime | address | | |
| opaque | | lifetime | | |
| | | | | |
| CGA | For | No | No | No |
| | lifetime of | | | |
| | (modifier | | | |
| | block + | | | |
| | public key) | | | |
| | | | | |
| Stable, | Within | No | No | No |
| semantically | single IPv6 | | | |
| opaque | link | | | |
| | | | | |
| Temporary | For temp | No | No | No |
| | address | | | |
| | lifetime | | | |
| | | | | |
| DHCPv6 | For lease | No | Depends on | No |
| | lifetime | | generation | |
| | | | mechanism | |
+--------------+-------------+----------+-------------+-------------+
Table 1: Privacy and Security Properties of IID Generation Mechanisms
<span class="grey">Cooper, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. IEEE-Identifier-Based IIDs</span>
As discussed in <a href="#section-3">Section 3</a>, addresses that use IIDs based on IEEE
identifiers are vulnerable to all four attacks. They allow
correlation and location tracking for the lifetime of the device
since IEEE identifiers last that long and their structure makes
address scanning and device exploits possible.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Static, Manually Configured IIDs</span>
Because static, manually configured IIDs are stable, both correlation
and location tracking are possible for the life of the address.
The extent to which location tracking can be successfully performed
depends, to some extent, on the uniqueness of the employed IID. For
example, one would expect "low byte" IIDs to be more widely reused
than, for example, IIDs where the whole 64 bits follow some pattern
that is unique to a specific organization. Widely reused IIDs will
typically lead to false positives when performing location tracking.
Whether manually configured addresses are vulnerable to address
scanning and device exploits depends on the specifics of how the IIDs
are generated.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Constant, Semantically Opaque IIDs</span>
Although a mechanism to generate a constant, semantically opaque IID
has not been standardized, it has been in wide use for many years on
at least one platform (Windows). Windows uses the random generation
mechanism described in [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] in lieu of generating an IEEE-
identifier-based IID. This mitigates the device-specific
exploitation and address-scanning attacks but still allows
correlation and location tracking because the IID is constant across
IPv6 links and time.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Cryptographically Generated IIDs</span>
Cryptographically Generated Addresses (CGAs) [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>] bind a hash of
the host's public key to an IPv6 address in the SEcure Neighbor
Discovery (SEND) protocol [<a href="./rfc3971" title=""SEcure Neighbor Discovery (SEND)"">RFC3971</a>]. CGAs may be regenerated for
each subnet prefix, but this is not required given that they are
computationally expensive to generate. A host using a CGA can be
correlated for as long as the lifetime of the combination of the
public key and the chosen modifier block since it is possible to
rotate modifier blocks without generating new public keys. Because
the cryptographic hash of the host's public key uses the subnet
prefix as an input, even if the host does not generate a new public
key or modifier block when it moves to a different IPv6 link, its
<span class="grey">Cooper, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
location cannot be tracked via the IID. CGAs do not allow device-
specific exploitation or address-scanning attacks.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Stable, Semantically Opaque IIDs</span>
[<a id="ref-RFC7217">RFC7217</a>] specifies an algorithm that generates, for each network
interface, a unique random IID per IPv6 link. The aforementioned
algorithm is employed not only for global unicast addresses, but also
for unique local unicast addresses and link-local unicast addresses
since these addresses may leak out via application protocols (e.g.,
IPv6 addresses embedded in email headers).
A host that stays connected to the same IPv6 link could therefore be
tracked at length, whereas a mobile host's activities could only be
correlated for the duration of each network connection. Location
tracking is not possible with these addresses. They also do not
allow device-specific exploitation or address-scanning attacks.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. Temporary IIDs</span>
A host that uses only a temporary address mitigates all four threats.
Its activities may only be correlated for the lifetime of a single
temporary address.
A host that configures both an IEEE-identifier-based IID and
temporary addresses makes the host vulnerable to the same attacks as
if temporary addresses were not in use, although the viability of
some of them depends on how the host uses each address. An attacker
can correlate all of the host's activities for which it uses its
IEEE-identifier-based IID. Once an attacker has obtained the IEEE-
identifier-based IID, location tracking becomes possible on other
IPv6 links even if the host only makes use of temporary addresses on
those other IPv6 links; the attacker can actively probe the other
IPv6 links for the presence of the IEEE-identifier-based IID.
Device-specific vulnerabilities can still be exploited. Address
scanning is also still possible because the IEEE-identifier-based
address can be probed.
If the host instead generates a constant, semantically opaque IID to
use in a stable address for server-like connections together with
temporary addresses for outbound connections (as is the default in
Windows), it sees some improvements over the previous scenario. The
address-scanning attacks and device-specific exploitation attacks are
no longer possible because the OUI is no longer embedded in any of
the host's addresses. However, correlation of some activities across
time and location tracking are both still possible because the
semantically opaque IID is constant. And once an attacker has
obtained the host's semantically opaque IID, location tracking is
<span class="grey">Cooper, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
possible on any network by probing for that IID, even if the host
only uses temporary addresses on those networks. However, if the
host generates but never uses a constant, semantically opaque IID, it
mitigates all four threats.
When used together with temporary addresses, the stable, semantically
opaque IID generation mechanism [<a href="./rfc7217" title=""A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"">RFC7217</a>] improves upon the previous
scenario by limiting the potential for correlation to the lifetime of
the stable address (which may still be lengthy for hosts that are not
mobile) and by eliminating the possibility for location tracking
(since a different IID is generated for each subnet prefix). As in
the previous scenario, a host that configures but does not use a
stable, semantically opaque address mitigates all four threats.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. DHCPv6 Generation of IIDs</span>
The security and privacy implications of DHCPv6-based addresses will
typically depend on whether the client requests an IA_NA (Identity
Association for Non-temporary Addresses) or an IA_TA (Identity
Association for Temporary Addresses) [<a href="./rfc3315" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">RFC3315</a>] and the specific
DHCPv6 server software being employed.
DHCPv6 temporary addresses have the same properties as SLAAC
temporary addresses (see <a href="#section-4.6">Section 4.6</a>). On the other hand, the
properties of DHCPv6 non-temporary addresses typically depend on the
specific DHCPv6 server software being employed. Recent releases of
most popular DHCPv6 server software typically lease random addresses
with a similar lease time as that of IPv4. Thus, these addresses can
be considered to be "stable, semantically opaque". [<a href="#ref-DHCPv6-IID">DHCPv6-IID</a>]
specifies an algorithm that can be employed by DHCPv6 servers to
generate "stable, semantically opaque" addresses.
On the other hand, some DHCPv6 software leases sequential addresses
(typically low-byte addresses). These addresses can be considered to
be stable addresses. The drawback of this address generation scheme
compared to "stable, semantically opaque" addresses is that, since
they follow specific patterns, they enable IPv6 address scans.
<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>. Transition and Coexistence Technologies</span>
Addresses specified based on transition or coexistence technologies
that embed an IPv4 address within an IPv6 address are not included in
Table 1 because their privacy and security properties are inherited
from the embedded address. For example, Teredo [<a href="./rfc4380" title=""Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)"">RFC4380</a>] specifies a
means to generate an IPv6 address from the underlying IPv4 address
and port, leaving many other bits set to zero. This makes it
relatively easy for an attacker to scan for IPv6 addresses by
guessing the Teredo client's IPv4 address and port (which for many
<span class="grey">Cooper, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
NATs is not randomized). For this reason, popular implementations
(e.g., Windows) began deviating from the standard by including 12
random bits in place of zero bits. This modification was later
standardized in [<a href="./rfc5991" title=""Teredo Security Updates"">RFC5991</a>].
Some other transition technologies (e.g., [<a href="./rfc5214" title=""Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"">RFC5214</a>], [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>])
specify means to generate an IPv6 address from an underlying IPv4
address without a port. Such mechanisms thus make it much easier for
an attacker to conduct an address scan than for mechanisms that
require finding a port number as well.
Finally, still other mechanisms (e.g., [<a href="./rfc7596" title=""Lightweight 4over6: An Extension to the Dual- Stack Lite Architecture"">RFC7596</a>], [<a href="./rfc7597" title=""Mapping of Address and Port with Encapsulation (MAP-E)"">RFC7597</a>],
[<a href="./rfc7599" title=""Mapping of Address and Port using Translation (MAP-T)"">RFC7599</a>]) are somewhere in between, using an IPv4 address and a port
set ID (which for many NATs is not randomized). In general, such
mechanisms are thus typically as easy to scan as in the Teredo
example above without the 12-bit mitigation.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Miscellaneous Issues with IPv6 Addressing</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Network Operation</span>
It is generally agreed that IPv6 addresses that vary over time in a
specific IPv6 link tend to increase the complexity of event logging,
trouble-shooting, enforcement of access controls and quality of
service, etc. As a result, some organizations disable the use of
temporary addresses [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] even at the expense of reduced privacy
[<a href="#ref-Broersma" title=""IPv6 Everywhere: Living with a Fully IPv6-enabled environment"">Broersma</a>].
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Compliance</span>
Some IPv6 compliance testing suites required (and might still
require) implementations to support IEEE-identifier-based IIDs in
order to be approved as compliant. This document recommends that
compliance testing suites be relaxed to allow other forms of address
generation that are more amenable to privacy.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Intellectual Property Rights (IPRs)</span>
Some IPv6 addressing techniques might be covered by Intellectual
Property rights, which might limit their implementation in different
operating systems. [<a href="#ref-CGA-IPR" title=""IPR Details: Microsoft's Statement about IPR claimed in RFC 3972"">CGA-IPR</a>] and [<a href="#ref-KAME-CGA" title=""The KAME IPR policy and concerns of some technologies which have IPR claims"">KAME-CGA</a>] discuss the IPRs on
CGAs.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
This whole document concerns the privacy and security properties of
different IPv6 address generation mechanisms.
<span class="grey">Cooper, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC2464">RFC2464</a>] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", <a href="./rfc2464">RFC 2464</a>, DOI 10.17487/RFC2464, December 1998,
<<a href="http://www.rfc-editor.org/info/rfc2464">http://www.rfc-editor.org/info/rfc2464</a>>.
[<a id="ref-RFC3315">RFC3315</a>] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, DOI 10.17487/RFC3315, July
2003, <<a href="http://www.rfc-editor.org/info/rfc3315">http://www.rfc-editor.org/info/rfc3315</a>>.
[<a id="ref-RFC3971">RFC3971</a>] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", <a href="./rfc3971">RFC 3971</a>,
DOI 10.17487/RFC3971, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc3971">http://www.rfc-editor.org/info/rfc3971</a>>.
[<a id="ref-RFC3972">RFC3972</a>] Aura, T., "Cryptographically Generated Addresses (CGA)",
<a href="./rfc3972">RFC 3972</a>, DOI 10.17487/RFC3972, March 2005,
<<a href="http://www.rfc-editor.org/info/rfc3972">http://www.rfc-editor.org/info/rfc3972</a>>.
[<a id="ref-RFC4380">RFC4380</a>] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", <a href="./rfc4380">RFC 4380</a>,
DOI 10.17487/RFC4380, February 2006,
<<a href="http://www.rfc-editor.org/info/rfc4380">http://www.rfc-editor.org/info/rfc4380</a>>.
[<a id="ref-RFC4862">RFC4862</a>] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", <a href="./rfc4862">RFC 4862</a>,
DOI 10.17487/RFC4862, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4862">http://www.rfc-editor.org/info/rfc4862</a>>.
[<a id="ref-RFC4941">RFC4941</a>] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", <a href="./rfc4941">RFC 4941</a>, DOI 10.17487/RFC4941, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4941">http://www.rfc-editor.org/info/rfc4941</a>>.
[<a id="ref-RFC5991">RFC5991</a>] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
Security Updates", <a href="./rfc5991">RFC 5991</a>, DOI 10.17487/RFC5991,
September 2010, <<a href="http://www.rfc-editor.org/info/rfc5991">http://www.rfc-editor.org/info/rfc5991</a>>.
<span class="grey">Cooper, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
[<a id="ref-RFC6724">RFC6724</a>] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", <a href="./rfc6724">RFC 6724</a>, DOI 10.17487/RFC6724, September 2012,
<<a href="http://www.rfc-editor.org/info/rfc6724">http://www.rfc-editor.org/info/rfc6724</a>>.
[<a id="ref-RFC7136">RFC7136</a>] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", <a href="./rfc7136">RFC 7136</a>, DOI 10.17487/RFC7136,
February 2014, <<a href="http://www.rfc-editor.org/info/rfc7136">http://www.rfc-editor.org/info/rfc7136</a>>.
[<a id="ref-RFC7217">RFC7217</a>] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", <a href="./rfc7217">RFC 7217</a>,
DOI 10.17487/RFC7217, April 2014,
<<a href="http://www.rfc-editor.org/info/rfc7217">http://www.rfc-editor.org/info/rfc7217</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-Broersma">Broersma</a>] Broersma, R., "IPv6 Everywhere: Living with a Fully
IPv6-enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010,
<<a href="http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf">http://www.ipv6.org.au/10ipv6summit/talks/</a>
<a href="http://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf">Ron_Broersma.pdf</a>>.
[<a id="ref-CGA-IPR">CGA-IPR</a>] IETF, "IPR Details: Microsoft's Statement about IPR
claimed in <a href="./rfc3972">RFC 3972</a>", November 2005,
<<a href="https://datatracker.ietf.org/ipr/676/">https://datatracker.ietf.org/ipr/676/</a>>.
[<a id="ref-DHCPv6-IID">DHCPv6-IID</a>]
Gont, F. and W. Liu, "A Method for Generating Semantically
Opaque Interface Identifiers with Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", Work in
Progress, <a href="./draft-ietf-dhc-stable-privacy-addresses-02">draft-ietf-dhc-stable-privacy-addresses-02</a>,
April 2015.
[<a id="ref-KAME-CGA">KAME-CGA</a>] The KAME Project, "The KAME IPR policy and concerns of
some technologies which have IPR claims", November 2005,
<<a href="http://www.kame.net/newsletter/20040525/">http://www.kame.net/newsletter/20040525/</a>>.
[<a id="ref-Microsoft">Microsoft</a>]
Microsoft, "IPv6 interface identifiers", 2013,
<<a href="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true">http://www.microsoft.com/resources/documentation/</a>
<a href="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true">windows/xp/all/proddocs/en-us/</a>
<a href="http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true">sag_ip_v6_imp_addr7.mspx?mfr=true</a>>.
[<a id="ref-Panopticlick">Panopticlick</a>]
Electronic Frontier Foundation, "Panopticlick", 2011,
<<a href="http://panopticlick.eff.org">http://panopticlick.eff.org</a>>.
<span class="grey">Cooper, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
[<a id="ref-RFC1971">RFC1971</a>] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", <a href="./rfc1971">RFC 1971</a>, DOI 10.17487/RFC1971, August
1996, <<a href="http://www.rfc-editor.org/info/rfc1971">http://www.rfc-editor.org/info/rfc1971</a>>.
[<a id="ref-RFC1972">RFC1972</a>] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", <a href="./rfc1972">RFC 1972</a>,
DOI 10.17487/RFC1972, August 1996,
<<a href="http://www.rfc-editor.org/info/rfc1972">http://www.rfc-editor.org/info/rfc1972</a>>.
[<a id="ref-RFC3041">RFC3041</a>] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", <a href="./rfc3041">RFC 3041</a>,
DOI 10.17487/RFC3041, January 2001,
<<a href="http://www.rfc-editor.org/info/rfc3041">http://www.rfc-editor.org/info/rfc3041</a>>.
[<a id="ref-RFC3261">RFC3261</a>] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", <a href="./rfc3261">RFC 3261</a>,
DOI 10.17487/RFC3261, June 2002,
<<a href="http://www.rfc-editor.org/info/rfc3261">http://www.rfc-editor.org/info/rfc3261</a>>.
[<a id="ref-RFC3314">RFC3314</a>] Wasserman, M., Ed., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
<a href="./rfc3314">RFC 3314</a>, DOI 10.17487/RFC3314, September 2002,
<<a href="http://www.rfc-editor.org/info/rfc3314">http://www.rfc-editor.org/info/rfc3314</a>>.
[<a id="ref-RFC3484">RFC3484</a>] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>,
DOI 10.17487/RFC3484, February 2003,
<<a href="http://www.rfc-editor.org/info/rfc3484">http://www.rfc-editor.org/info/rfc3484</a>>.
[<a id="ref-RFC5214">RFC5214</a>] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP)", <a href="./rfc5214">RFC 5214</a>,
DOI 10.17487/RFC5214, March 2008,
<<a href="http://www.rfc-editor.org/info/rfc5214">http://www.rfc-editor.org/info/rfc5214</a>>.
[<a id="ref-RFC6052">RFC6052</a>] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", <a href="./rfc6052">RFC 6052</a>,
DOI 10.17487/RFC6052, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6052">http://www.rfc-editor.org/info/rfc6052</a>>.
[<a id="ref-RFC6265">RFC6265</a>] Barth, A., "HTTP State Management Mechanism", <a href="./rfc6265">RFC 6265</a>,
DOI 10.17487/RFC6265, April 2011,
<<a href="http://www.rfc-editor.org/info/rfc6265">http://www.rfc-editor.org/info/rfc6265</a>>.
<span class="grey">Cooper, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
[<a id="ref-RFC6973">RFC6973</a>] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", <a href="./rfc6973">RFC 6973</a>,
DOI 10.17487/RFC6973, July 2013,
<<a href="http://www.rfc-editor.org/info/rfc6973">http://www.rfc-editor.org/info/rfc6973</a>>.
[<a id="ref-RFC7421">RFC7421</a>] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", <a href="./rfc7421">RFC 7421</a>,
DOI 10.17487/RFC7421, January 2015,
<<a href="http://www.rfc-editor.org/info/rfc7421">http://www.rfc-editor.org/info/rfc7421</a>>.
[<a id="ref-RFC7596">RFC7596</a>] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", <a href="./rfc7596">RFC 7596</a>, DOI 10.17487/RFC7596,
July 2015, <<a href="http://www.rfc-editor.org/info/rfc7596">http://www.rfc-editor.org/info/rfc7596</a>>.
[<a id="ref-RFC7597">RFC7597</a>] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", <a href="./rfc7597">RFC 7597</a>,
DOI 10.17487/RFC7597, July 2015,
<<a href="http://www.rfc-editor.org/info/rfc7597">http://www.rfc-editor.org/info/rfc7597</a>>.
[<a id="ref-RFC7599">RFC7599</a>] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S.,
and T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", <a href="./rfc7599">RFC 7599</a>, DOI 10.17487/RFC7599, July
2015, <<a href="http://www.rfc-editor.org/info/rfc7599">http://www.rfc-editor.org/info/rfc7599</a>>.
[<a id="ref-RFC7707">RFC7707</a>] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", <a href="./rfc7707">RFC 7707</a>, DOI 10.17487/RFC7707, March 2016,
<<a href="http://www.rfc-editor.org/info/rfc7707">http://www.rfc-editor.org/info/rfc7707</a>>.
<span class="grey">Cooper, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7721">RFC 7721</a> IPv6 Address Generation Privacy March 2016</span>
Acknowledgements
The authors would like to thank Bernard Aboba, Brian Carpenter, Tim
Chown, Lorenzo Colitti, Rich Draves, Robert Hinden, Robert Moskowitz,
Erik Nordmark, Mark Smith, Ole Troan, and James Woodyatt for
providing valuable comments on earlier draft versions of this
document.
Authors' Addresses
Alissa Cooper
Cisco
707 Tasman Drive
Milpitas, CA 95035
United States
Phone: +1-408-902-3950
Email: alcoop@cisco.com
URI: <a href="https://www.cisco.com/">https://www.cisco.com/</a>
Fernando Gont
Huawei Technologies
Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706
Argentina
Phone: +54 11 4650 8472
Email: fgont@si6networks.com
URI: <a href="http://www.si6networks.com">http://www.si6networks.com</a>
Dave Thaler
Microsoft
One Microsoft Way
Redmond, WA 98052
United States
Phone: +1 425 703 8835
Email: dthaler@microsoft.com
Cooper, et al. Informational [Page 18]
</pre>
|
