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
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
|
<pre>Network Working Group C. Huitema
Request for Comments: 3904 Microsoft
Category: Informational R. Austein
ISC
S. Satapati
Cisco Systems, Inc.
R. van der Pol
NLnet Labs
September 2004
<span class="h1">Evaluation of IPv6 Transition Mechanisms for Unmanaged Networks</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document analyzes issues involved in the transition of
"unmanaged networks" from IPv4 to IPv6. Unmanaged networks typically
correspond to home networks or small office networks. A companion
paper analyzes out the requirements for mechanisms needed in various
transition scenarios of these networks to IPv6. Starting from this
analysis, we evaluate the suitability of mechanisms that have already
been specified, proposed, or deployed.
Table of Contents:
<a href="#section-1">1</a>. Introduction ................................................. <a href="#page-2">2</a>
<a href="#section-2">2</a>. Evaluation of Tunneling Solutions ............................ <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Comparing Automatic and Configured Solutions ........... <a href="#page-3">3</a>
<a href="#section-2.1.1">2.1.1</a>. Path Optimization in Automatic Tunnels ......... <a href="#page-4">4</a>
<a href="#section-2.1.2">2.1.2</a>. Automatic Tunnels and Relays ................... <a href="#page-4">4</a>
<a href="#section-2.1.3">2.1.3</a>. The Risk of Several Parallel IPv6 Internets .... <a href="#page-5">5</a>
<a href="#section-2.1.4">2.1.4</a>. Lifespan of Transition Technologies ............ <a href="#page-6">6</a>
<a href="#section-2.2">2.2</a>. Cost and Benefits of NAT Traversal ..................... <a href="#page-6">6</a>
<a href="#section-2.2.1">2.2.1</a>. Cost of NAT Traversal .......................... <a href="#page-7">7</a>
<a href="#section-2.2.2">2.2.2</a>. Types of NAT ................................... <a href="#page-7">7</a>
<a href="#section-2.2.3">2.2.3</a>. Reuse of Existing Mechanisms ................... <a href="#page-8">8</a>
<a href="#section-2.3">2.3</a>. Development of Transition Mechanisms ................... <a href="#page-8">8</a>
<span class="grey">Huitema, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
<a href="#section-3">3</a>. Meeting Case A Requirements .................................. <a href="#page-9">9</a>
<a href="#section-3.1">3.1</a>. Evaluation of Connectivity Mechanisms .................. <a href="#page-9">9</a>
<a href="#section-3.2">3.2</a>. Security Considerations in Case A ...................... <a href="#page-9">9</a>
<a href="#section-4">4</a>. Meeting case B Requirements .................................. <a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. Connectivity ........................................... <a href="#page-10">10</a>
<a href="#section-4.1.1">4.1.1</a>. Extending a Subnet to Span Multiple Links ...... <a href="#page-10">10</a>
<a href="#section-4.1.2">4.1.2</a>. Explicit Prefix Delegation ..................... <a href="#page-11">11</a>
<a href="#section-4.1.3">4.1.3</a>. Recommendation ................................. <a href="#page-11">11</a>
4.2. Communication Between IPv4-only and IPv6-Capable Nodes . 11
<a href="#section-4.3">4.3</a>. Resolution of Names to IPv6 Addresses .................. <a href="#page-12">12</a>
<a href="#section-4.3.1">4.3.1</a>. Provisioning the Address of a DNS Resolver ..... <a href="#page-12">12</a>
<a href="#section-4.3.2">4.3.2</a>. Publishing IPv6 Addresses to the Internet ...... <a href="#page-12">12</a>
<a href="#section-4.3.3">4.3.3</a>. Resolving the IPv6 Addresses of Local Hosts .... <a href="#page-13">13</a>
<a href="#section-4.3.4">4.3.4</a>. Recommendations for Name Resolution ............ <a href="#page-13">13</a>
<a href="#section-4.4">4.4</a>. Security Considerations in Case B ...................... <a href="#page-14">14</a>
<a href="#section-5">5</a>. Meeting Case C Requirements .................................. <a href="#page-14">14</a>
<a href="#section-5.1">5.1</a>. Connectivity ........................................... <a href="#page-14">14</a>
<a href="#section-6">6</a>. Meeting the Case D Requirements .............................. <a href="#page-14">14</a>
<a href="#section-6.1">6.1</a>. IPv6 Addressing Requirements ........................... <a href="#page-15">15</a>
<a href="#section-6.2">6.2</a>. IPv4 Connectivity Requirements ........................ <a href="#page-15">15</a>
<a href="#section-6.3">6.3</a>. Naming Requirements .................................... <a href="#page-15">15</a>
<a href="#section-7">7</a>. Recommendations .............................................. <a href="#page-15">15</a>
<a href="#section-8">8</a>. Security Considerations ...................................... <a href="#page-16">16</a>
<a href="#section-9">9</a>. Acknowledgements ............................................. <a href="#page-16">16</a>
<a href="#section-10">10</a>. References ................................................... <a href="#page-16">16</a>
<a href="#section-11">11</a>. Authors' Addresses ........................................... <a href="#page-18">18</a>
<a href="#section-12">12</a>. Full Copyright Statement ..................................... <a href="#page-19">19</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document analyzes the issues involved in the transition from
IPv4 to IPv6 [<a href="#ref-IPV6" title=""Internet Protocol, Version 6 (IPv6) Specification"">IPV6</a>]. In a companion paper [<a href="#ref-UNMANREQ" title=""Unmanaged Networks IPv6 Transition Scenarios"">UNMANREQ</a>] we defined the
"unmanaged networks", which typically correspond to home networks or
small office networks, and the requirements for transition mechanisms
in various scenarios of transition to IPv6.
The requirements for unmanaged networks are expressed by analyzing
four classes of applications: local, client, peer to peer, and
servers, and are considering four cases of deployment. These are:
A) a gateway which does not provide IPv6 at all;
B) a dual-stack gateway connected to a dual-stack ISP;
C) a dual-stack gateway connected to an IPv4-only ISP; and
D) a gateway connected to an IPv6-only ISP.
During the transition phase from IPv4 to IPv6 there will be IPv4-
only, dual-stack, or IPv6-only nodes. In this document, we make the
hypothesis that the IPv6-only nodes do not need to communicate with
<span class="grey">Huitema, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
IPv4-only nodes; devices that want to communicate with both IPv4 and
IPv6 nodes are expected to implement both IPv4 and IPv6, i.e., be
dual-stack.
The issues involved are described in the next sections. This
analysis outlines two types of requirements: connectivity
requirements, i.e., how to ensure that nodes can exchange IP packets,
and naming requirements, i.e., how to ensure that nodes can resolve
each-other's names. The connectivity requirements often require
tunneling solutions. We devote the first section of this memo to an
evaluation of various tunneling solutions.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Evaluation of Tunneling Solutions</span>
In the case A and case C scenarios described in [<a href="#ref-UNMANREQ" title=""Unmanaged Networks IPv6 Transition Scenarios"">UNMANREQ</a>], the
unmanaged network cannot obtain IPv6 service, at least natively, from
its ISP. In these cases, the IPv6 service will have to be provided
through some form of tunnel. There have been multiple proposals on
different ways to tunnel IPv6 through an IPv4 service. We believe
that these proposals can be categorized according to two important
properties:
* Is the deployment automatic, or does it require explicit
configuration or service provisioning?
* Does the proposal allow for the traversal of a NAT?
These two questions divide the solution space into four broad
classes. Each of these classes has specific advantages and risks,
which we will now develop.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Comparing Automatic and Configured Solutions</span>
It is possible to broadly classify tunneling solutions as either
"automatic" or "configured". In an automatic solution, a host or a
router builds an IPv6 address or an IPv6 prefix by combining a pre-
defined prefix with some local attribute, such as a local IPv4
address [<a href="#ref-6TO4" title=""Connection of IPv6 Domains via IPv4 Clouds"">6TO4</a>] or the combination of an address and a port number
[<a href="#ref-TEREDO" title=""Teredo: Tunneling IPv6 over UDP through NATs"">TEREDO</a>]. Another typical and very important characteristic of an
automatic solution is they aim to work with a minimal amount of
support or infrastructure for IPv6 in the local or remote ISPs.
In a configured solution, a host or a router identifies itself to a
tunneling service to set up a "configured tunnel" with an explicitly
defined "tunnel router". The amount of actual configuration may vary
from manually configured static tunnels to dynamic tunnel services
requiring only the configuration of a "tunnel broker", or even a
completely automatic discovery of the tunnel router.
<span class="grey">Huitema, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
Configured tunnels have many advantages over automatic tunnels. The
client is explicitly identified and can obtain a stable IPv6 address.
The service provider is also well identified and can be held
responsible for the quality of the service. It is possible to route
multicast packets over the established tunnel. There is a clear
address delegation path, which enables easy support for reverse DNS
lookups.
Automatic tunnels generally cannot provide the same level of service.
The IPv6 address is only as stable as the underlying IPv4 address,
the quality of service depends on relays operated by third parties,
there is typically no support for multicast, and there is often no
easy way to support reverse DNS lookups (although some workarounds
are probably possible). However, automatic tunnels have other
advantages. They are obviously easier to configure, since there is
no need for an explicit relation with a tunnel service. They may
also be more efficient in some cases, as they allow for "path
optimization".
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Path Optimization in Automatic Tunnels</span>
In automatic tunnels like [<a href="#ref-TEREDO" title=""Teredo: Tunneling IPv6 over UDP through NATs"">TEREDO</a>] and [<a href="#ref-6TO4" title=""Connection of IPv6 Domains via IPv4 Clouds"">6TO4</a>], the bulk of the
traffic between two nodes using the same technology is exchanged on a
direct path between the endpoints, using the IPv4 services to which
the endpoints already subscribe. By contrast, the configured tunnel
servers carry all the traffic exchanged by the tunnel client.
Path optimization is not a big issue if the tunnel server is close to
the client on the natural path between the client and its peers.
However, if the tunnel server is operated by a third party, this
third party will have to bear the cost of provisioning the bandwidth
used by the client. The associated costs can be significant.
These costs are largely absent when the tunnels are configured by the
same ISP that provides the IPv4 service. The ISP can place the
tunnel end-points close to the client, i.e., mostly on the direct
path between the client and its peers.
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Automatic Tunnels and Relays</span>
The economics arguments related to path optimization favor either
configured tunnels provided by the local ISP or automatic tunneling
regardless of the co-operation of ISPs. However, automatic solutions
require that relays be configured throughout the Internet. If a host
that obtained connectivity through an automatic tunnel service wants
to communicate with a "native" host or with a host using a configured
<span class="grey">Huitema, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
tunnel, it will need to use a relay service, and someone will have to
provide and pay for that service. We cannot escape economic
considerations for the deployment of these relays.
It is desirable to locate these relays close to the "native host".
During the transition period, the native ISPs have an interest in
providing a relay service for use by their native subscribers. Their
subscribers will enjoy better connectivity, and will therefore be
happier. Providing the service does not result in much extra
bandwidth requirement: the packets are exchanged between the local
subscribers and the Internet; they are simply using a v6-v4 path
instead of a v6-v6 path. (The native ISPs do not have an incentive
to provide relays for general use; they are expected to restrict
access to these relays to their customers.)
We should note however that different automatic tunneling techniques
have different deployment conditions.
<span class="h4"><a class="selflink" id="section-2.1.3" href="#section-2.1.3">2.1.3</a>. The Risk of Several Parallel IPv6 Internets</span>
In an early deployment of the Teredo service by Microsoft, the relays
are provided by the native (or 6to4) hosts themselves. The native or
6to4 hosts are de-facto "multi-homed" to native and Teredo hosts,
although they never publish a Teredo address in the DNS or otherwise.
When a native host communicates with a Teredo host, the first packets
are exchanged through the native interface and relayed by the Teredo
server, while the subsequent packets are tunneled "end-to-end" over
IPv4 and UDP. This enables deployment of Teredo without having to
field an infrastructure of relays in the network.
This type of solution carries the implicit risk of developing two
parallel IPv6 Internets, one native and one using Teredo: in order to
communicate with a Teredo-only host, a native IPv6 host has to
implement a Teredo interface. The Teredo implementations try to
mitigate this risk by always preferring native paths when available,
but a true mitigation requires that native hosts do not have to
implement the transition technology. This requires cooperation from
the IPv6 ISP, who will have to support the relays. An IPv6 ISP that
really wants to isolate its customers from the Teredo technology can
do that by providing native connectivity and a Teredo relay. The
ISP's customers will not need to implement their own relay.
Communication between 6to4 networks and native networks uses a
different structure. There are two relays, one for each direction of
communication. The native host sends its packets through the nearest
6to4 router, i.e., the closest router advertising the 2002::/16
prefix through the IPv6 routing tables; the 6to4 network sends its
packet through a 6to4 relay that is either explicitly configured or
<span class="grey">Huitema, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
discovered through the 6to4 anycast address 192.88.99.1
[<a href="#ref-6TO4ANYCAST" title=""An Anycast Prefix for 6to4 Relay Routers"">6TO4ANYCAST</a>]. The experience so far is that simple 6to4 routers are
easy to deploy, but 6to4 relays are scarce. If there are too few
relays, these relays will create a bottleneck. The communications
between 6to4 and native networks will be slower than the direct
communications between 6to4 hosts. This will create an incentive for
native hosts to somehow "multi-home" to 6to4, de facto creating two
parallel Internets, 6to4 and native. This risk will only be
mitigated if there is a sufficient deployment of 6to4 relays.
The configured tunnel solutions do not carry this type of risk.
<span class="h4"><a class="selflink" id="section-2.1.4" href="#section-2.1.4">2.1.4</a>. Lifespan of Transition Technologies</span>
A related issue is the lifespan of the transition solutions. Since
automatic tunneling technologies enable an automatic deployment,
there is a risk that some hosts never migrate out of the transition.
The risk is arguably less for explicit tunnels: the ISPs who provide
the tunnels have an incentive to replace them with a native solution
as soon as possible.
Many implementations of automatic transition technologies incorporate
an "implicit sunset" mechanism: the hosts will not configure a
transition technology address if they have native connectivity; the
address selection mechanisms will prefer native addresses when
available. The transition technologies will stop being used
eventually, when native connectivity has been deployed everywhere.
However, the "implicit sunset" mechanism does not provide any hard
guarantee that transition will be complete at a certain date.
Yet, the support of transition technologies has a cost for the entire
network: native IPv6 ISPS have to support relays in order to provide
good performance and avoid the "parallel Internet" syndrome. These
costs may be acceptable during an initial deployment phase, but they
can certainly not be supported for an indefinite period. The
"implicit sunset" mechanisms may not be sufficient to guarantee a
finite lifespan of the transition.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Cost and Benefits of NAT Traversal</span>
During the transition, some hosts will be located behind IPv4 NATs.
In order to participate in the transition, these hosts will have to
use a tunneling mechanism designed to traverse NAT.
We may ask whether NAT traversal should be a generic property of any
transition technology, or whether it makes sense to develop two types
of technologies, some "NAT capable" and some not. An important
question is also which kinds of NAT boxes one should be able to
<span class="grey">Huitema, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
traverse. One should probably also consider whether it is necessary
to build an IPv6 specific NAT traversal mechanism, or whether it is
possible to combine an existing IPv4 NAT traversal mechanism with
some form of IPv6 in IPv4 tunneling. There are many IPv4 NAT
traversal mechanisms; thus one may ask whether these need re-
invention, especially when they are already complex.
A related question is whether the NAT traversal technology should use
automatic tunnels or configured tunnels. We saw in the previous
section that one can argue both sides of this issue. In fact, there
are already deployed automatic and configured solutions, so the
reality is that we will probably see both.
<span class="h4"><a class="selflink" id="section-2.2.1" href="#section-2.2.1">2.2.1</a>. Cost of NAT Traversal</span>
NAT traversal technologies generally involve encapsulating IPv6
packets inside a transport protocol that is known to traverse NAT,
such as UDP or TCP. These transport technologies require
significantly more overhead than the simple tunneling over IPv4 used
in 6to4 or in IPv6 in IPv4 tunnels. For example, solutions based on
UDP require the frequent transmission of "keep alive" packets to
maintain a "mapping" in the NAT; solutions based on TCP may not
require such a mechanism, but they incur the risk of "head of queue
blocking", which may translate in poor performance. Given the
difference in performance, it makes sense to consider two types of
transition technologies, some capable of traversing NAT and some
aiming at the best performance.
<span class="h4"><a class="selflink" id="section-2.2.2" href="#section-2.2.2">2.2.2</a>. Types of NAT</span>
There are many kinds of NAT on the market. Different models
implement different strategies for address and port allocations, and
different types of timers. It is desirable to find solutions that
cover "almost all" models of NAT.
A configured tunnel solution will generally make fewer hypotheses on
the behavior of the NAT than an automatic solution. The configured
solutions only need to establish a connection between an internal
node and a server; this communication pattern is supported by pretty
much all NAT configurations. The variability will come from the type
of transport protocols that the NAT supports, especially when the NAT
also implements "firewall" functions. Some models will allow
establishment of a single "protocol 41" tunnel, while some may
prevent this type of transmission. Some models will allow UDP
transmission, while other may only allow TCP, or possibly HTTP.
<span class="grey">Huitema, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
The automatic solutions have to rely on a "lowest common denominator"
that is likely to be accepted by most models of NAT. In practice,
this common denominator is UDP. UDP based NAT traversal is required
by many applications, e.g., networked games or voice over IP. The
experience shows that most recent "home routers" are designed to
support these applications. In some edge cases, the automatic
solutions will require explicit configuration of a port in the home
router, using the so-called "DMZ" functions; however, these functions
are hard to use in an "unmanaged network" scenario.
<span class="h4"><a class="selflink" id="section-2.2.3" href="#section-2.2.3">2.2.3</a>. Reuse of Existing Mechanisms</span>
NAT traversal is not a problem for IPv6 alone. Many IPv4
applications have developed solutions, or kludges, to enable
communication across a NAT.
Virtual Private Networks are established by installing tunnels
between VPN clients and VPN servers. These tunnels are designed
today to carry IPv4, but in many cases could easily carry IPv6. For
example, the proposed IETF standard, L2TP, includes a PPP layer that
can encapsulate IPv6 as well as IPv4. Several NAT models are
explicitly designed to pass VPN traffic, and several VPN solutions
have special provisions to traverse NAT. When we study the
establishment of configured tunnels through NAT, it makes a lot of
sense to consider existing VPN solutions.
[<a id="ref-STUN">STUN</a>] is a protocol designed to facilitate the establishment of UDP
associations through NAT, by letting nodes behind NAT discover their
"external" address. The same function is required for automatic
tunneling through NAT, and one could consider reusing the STUN
specification as part of an automatic tunneling solution. However,
the automatic solutions also require a mechanism of bubbles to
establish the initial path through a NAT. This mechanism is not
present in STUN. It is not clear that a combination of STUN and a
bubble mechanism would have a technical advantage over a solution
specifically designed for automatic tunneling through NAT.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Development of Transition Mechanisms</span>
The previous sections make the case for the development of four
transition mechanism, covering the following 4 configurations:
- Configured tunnel over IPv4 in the absence of NAT;
- Automatic tunnel over IPv4 in the absence of NAT;
- Configured tunnel across a NAT;
- Automatic tunnel across a NAT.
<span class="grey">Huitema, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
Teredo is an example of an already designed solution for automatic
tunnels across a NAT; 6to4 is an example of a solution for automatic
tunnels over IPv4 in the absence of NAT.
All solutions should be designed to meet generic requirements such as
security, scalability, support for reverse name lookup, or simple
management. In particular, automatic tunneling solutions may need to
be augmented with a special purpose reverse DNS lookup mechanism,
while configured tunnel solutions would benefit from an automatic
service configuration mechanism.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Meeting Case A Requirements</span>
In case A, isolated hosts need to acquire some form of connectivity.
In this section, we first evaluate how mechanisms already defined or
being worked on in the IETF meet this requirement. We then consider
the "remaining holes" and recommend specific developments.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Evaluation of Connectivity Mechanisms</span>
In case A, IPv6 capable hosts seek IPv6 connectivity in order to
communicate with applications in the global IPv6 Internet. The
connectivity requirement can be met using either configured tunnels
or automatic tunnels.
If the host is located behind a NAT, the tunneling technology should
be designed to traverse NAT; tunneling technologies that do not
support NAT traversal can obviously be used if the host is not
located behind a NAT.
When the local ISP is willing to provide a configured tunnel
solution, we should make it easy for the host in case A to use it.
The requirements for such a service will be presented in another
document.
An automatic solution like Teredo appears to be a good fit for
providing IPv6 connectivity to hosts behind NAT, in case A of IPv6
deployment. The service is designed for minimizing the cost of
deploying the server, which matches the requirement of minimizing the
cost of the "supporting infrastructure".
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Security Considerations in Case A</span>
A characteristic of case A is that an isolated host acquires global
IPv6 connectivity, using either Teredo or an alternative tunneling
mechanism. If no precaution is taken, there is a risk of exposing to
the global Internet some applications and services that are only
expected to serve local hosts, e.g., those located behind the NAT
<span class="grey">Huitema, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
when a NAT is present. Developers and administrators should make
sure that the global IPv6 connectivity is restricted to only those
applications that are expressly designed for global Internet
connectivity. The users should be able to configure which
applications get IPv6 connectivity to the Internet and which should
not.
Any solution to the NAT traversal problem is likely to involve
relays. There are concerns that improperly designed protocols or
improperly managed relays could open new avenues for attacks against
Internet services. This issue should be addressed and mitigated in
the design of the NAT traversal protocols and in the deployment
guides for relays.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Meeting Case B Requirements</span>
In case B, we assume that the gateway and the ISP are both dual-
stack. The hosts on the local network may be IPv4-only, dual-stack,
or IPv6-only. The main requirements are: prefix delegation and name
resolution. We also study the potential need for communication
between IPv4 and IPv6 hosts, and conclude that a dual-stack approach
is preferable.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Connectivity</span>
The gateway must be able to acquire an IPv6 prefix, delegated by the
ISP. This can be done through explicit prefix delegation (e.g.,
[<a href="#ref-DHCPV6" title=""Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">DHCPV6</a>, <a href="#ref-PREFIXDHCPV6" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">PREFIXDHCPV6</a>]), or if the ISP is advertising a /64 prefix on
the link, such a link can be extended by the use of an ND proxy or a
bridge.
An ND proxy can also be used to extend a /64 prefix to multiple
physical links of different properties (e.g., an Ethernet and a PPP
link).
<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>. Extending a Subnet to Span Multiple Links</span>
A /64 subnet can be extended to span multiple physical links using a
bridge or ND proxy. Bridges can be used when bridging multiple
similar media (mainly, Ethernet segments). On the other hand, an ND
proxy must be used if a /64 prefix has to be shared across media
(e.g., an upstream PPP link and a downstream Ethernet), or if an
interface cannot be put into promiscuous mode (e.g., an upstream
wireless link).
Extending a single subnet to span from the ISP to all of the
unmanaged network is not recommended, and prefix delegation should be
used when available. However, sometimes it is unavoidable. In
<span class="grey">Huitema, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
addition, sometimes it's necessary to extend a subnet in the
unmanaged network, at the "customer-side" of the gateway, and
changing the topology using routing might require too much expertise.
The ND proxy method results in the sharing of the same prefix over
several links, a procedure generally known as "multi-link subnet".
This sharing has effects on neighbor discovery protocols, and
possibly also on other protocols such as LLMNR [<a href="#ref-LLMNR" title=""Linklocal Multicast Name Resolution (LLMNR)"">LLMNR</a>] that rely on
"link local multicast". These effects need to be carefully studied.
<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>. Explicit Prefix Delegation</span>
Several networks have already started using an explicit prefix
delegation mechanism using DHCPv6. In this mechanism, the gateway
uses a DHCP request to obtain an adequate prefix from a DHCP server
managed by the Internet Service Provider. The DHCP request is
expected to carry proper identification of the gateway, which enables
the ISP to implement prefix delegation policies. It is expected that
the ISP assigns a /48 to the customer. The gateway should
automatically assign /64s out of this /48 to its internal links.
DHCP is insecure unless authentication is used. This may be a
particular problem if the link between gateway and ISP is shared by
multiple subscribers. DHCP specification includes authentication
options, but the operational procedures for managing the keys and
methods for sharing the required information between the customer and
the ISP are unclear. To be secure in such an environment in
practice, the practical details of managing the DHCP authentication
need to be analyzed.
<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>. Recommendation</span>
The ND proxy and DHCP methods appear to have complementary domains of
application. ND proxy is a simple method that corresponds well to
the "informal sharing" of a link, while explicit delegation provides
strong administrative control. Both methods require development:
specify the interaction with neighbor discovery for ND proxy; provide
security guidelines for explicit delegation.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Communication Between IPv4-only and IPv6-capable Nodes</span>
During the transition phase from IPv4 to IPv6, there will be IPv4-
only, dual-stack, and IPv6-only nodes. In theory, there may be a
need to provide some interconnection services so that IPv4-only and
IPv6-only hosts can communicate. However, it is hard to develop a
translation service that does not have unwanted side effects on the
efficiency or the security of communications. As a consequence, the
authors recommend that, if a device requires communication with
<span class="grey">Huitema, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
IPv4-only hosts, this device implements an IPv4 stack. The only
devices that should have IPv6-only connectivity are those that are
intended to only communicate with IPv6 hosts.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Resolution of Names to IPv6 Addresses</span>
There are three types of name resolution services that should be
provided in case B: local IPv6 capable hosts must be able to obtain
the IPv6 addresses of correspondent hosts on the Internet, they
should be able to publish their address if they want to be accessed
from the Internet, and they should be able to obtain the IPv6 address
of other local IPv6 hosts. These three problems are described in the
next sections. Operational considerations and issues with IPv6 DNS
are analyzed in [<a href="#ref-DNSOPV6" title=""Operational Considerations and Issues with IPv6 DNS"">DNSOPV6</a>].
<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>. Provisioning the Address of a DNS Resolver</span>
In an unmanaged environment, IPv4 hosts usually obtain the address of
the local DNS resolver through DHCPv4; the DHCPv4 service is
generally provided by the gateway. The gateway will also use DHCPv4
to obtain the address of a suitable resolver from the local Internet
service provider.
The DHCPv4 solution will suffice in practice for the gateway and also
for the dual-stack hosts. There is evidence that DNS servers
accessed over IPv4 can serve arbitrary DNS records, including AAAA
records.
Just using DHCPv4 will not be an adequate solution for IPv6-only
local hosts. The DHCP working group has defined how to use
(stateless) DHCPv6 to obtain the address of the DNS server
[<a href="#ref-DNSDHCPV6" title=""DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">DNSDHCPV6</a>]. DHCPv6 and several other possibilities are being looked
at in the DNSOP Working Group.
<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>. Publishing IPv6 Addresses to the Internet</span>
IPv6 capable hosts may be willing to provide services accessible from
the global Internet. They will thus need to publish their address in
a server that is publicly available. IPv4 hosts in unmanaged
networks have a similar problem today, which they solve using one of
three possible solutions:
* Manual configuration of a stable address in a DNS server;
* Dynamic configuration using the standard dynamic DNS protocol;
* Dynamic configuration using an ad hoc protocol.
<span class="grey">Huitema, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
Manual configuration of stable addresses is not satisfactory in an
unmanaged IPv6 network: the prefix allocated to the gateway may or
may not be stable, and in any case, copying long hexadecimal strings
through a manual procedure is error prone.
Dynamic configuration using the same type of ad hoc protocols that
are common today is indeed possible, but the IETF should encourage
the use of standard solutions based on Dynamic DNS (DDNS).
<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>. Resolving the IPv6 Addresses of Local Hosts</span>
There are two possible ways of resolving the IPv6 addresses of local
hosts: one may either publish the IPv6 addresses in a DNS server for
the local domain, or one may use a peer-to-peer address resolution
protocol such as LLMNR.
When a DNS server is used, this server could in theory be located
anywhere on the Internet. There is however a very strong argument
for using a local server, which will remain reachable even if the
network connectivity is down.
The use of a local server requires that IPv6 capable hosts discover
this server, as explained in 4.3.1, and then that they use a protocol
such as DDNS to publish their IPv6 addresses to this server. In
practice, the DNS address discovered in 4.3.1 will often be the
address of the gateway itself, and the local server will thus be the
gateway.
An alternative to using a local server is LLMNR, which uses a
multicast mechanism to resolve DNS requests. LLMNR does not require
any service from the gateway, and also does not require that hosts
use DDNS. An important problem is that some networks only have
limited support for multicast transmission, for example, multicast
transmission on 802.11 network is error prone. However, unmanaged
networks also use multicast for neighbor discovery [<a href="#ref-NEIGHBOR" title=""Neighbor Discovery for IP Version 6 (IPv6)"">NEIGHBOR</a>]; the
requirements of ND and LLMNR are similar; if a link technology
supports use of ND, it can also enable use of LLMNR.
<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>. Recommendations for Name Resolution</span>
The IETF should quickly provide a recommended procedure for
provisioning the DNS resolver in IPv6-only hosts.
The most plausible candidate for local name resolution appears to be
LLMNR; the IETF should quickly proceed to the standardization of that
protocol.
<span class="grey">Huitema, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Security Considerations in Case B</span>
The case B solutions provide global IPv6 connectivity to the local
hosts. Removing the limit to connectivity imposed by NAT is both a
feature and a risk. Implementations should carefully limit global
IPv6 connectivity to only those applications that are specifically
designed to operate on the global Internet. Local applications, for
example, could be restricted to only use link-local addresses, or
addresses whose most significant bits match the prefix of the local
subnet, e.g., a prefix advertised as "on link" in a local router
advertisement. There is a debate as to whether such restrictions
should be "per-site" or "per-link", but this is not a serious issue
when an unmanaged network is composed of a single link.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Meeting Case C Requirements</span>
Case C is very similar to case B, the difference being that the ISP
is not dual-stack. The gateway must thus use some form of tunneling
mechanism to obtain IPv6 connectivity, and an address prefix.
A simplified form of case B is a single host with a global IPv4
address, i.e., with a direct connection to the IPv4 Internet. This
host will be able to use the same tunneling mechanisms as a gateway.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Connectivity</span>
Connectivity in case C requires some form of tunneling of IPv6 over
IPv4. The various tunneling solutions are discussed in <a href="#section-2">section 2</a>.
The requirements of case C can be solved by an automatic tunneling
mechanism such as 6to4 [<a href="#ref-6TO4" title=""Connection of IPv6 Domains via IPv4 Clouds"">6TO4</a>]. An alternative may be the use of a
configured tunnels mechanism [<a href="#ref-TUNNELS" title=""IPv6 Tunnel Broker"">TUNNELS</a>], but as the local ISP is not
IPv6-enabled, this may not be feasible. The practical conclusion of
our analysis is that "upgraded gateways" will probably support the
6to4 technology, and will have an optional configuration option for
"configured tunnels".
The tunnel broker technology should be augmented to include support
for some form of automatic configuration.
Due to concerns with potential overload of public 6to4 relays, the
6to4 implementations should include a configuration option that
allows the user to take advantage of specific relays.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Meeting the Case D Requirements</span>
In case D, the ISP only provides IPv6 services.
<span class="grey">Huitema, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IPv6 Addressing Requirements</span>
We expect IPv6 addressing in case D to proceed similarly to case B,
i.e., use either an ND proxy or explicit prefix delegation through
DHCPv6 to provision an IPv6 prefix on the gateway.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. IPv4 Connectivity Requirements</span>
Local IPv4 capable hosts may still want to access IPv4-only services.
The proper way to do this for dual-stack nodes in the unmanaged
network is to develop a form of "IPv4 over IPv6" tunneling. There
are no standardized solutions and the IETF has devoted very little
effort to this issue, although there is ongoing work with [<a href="#ref-DSTM" title=""Dual Stack Transition Mechanism"">DSTM</a>] and
[<a href="#ref-TSP" title=""IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)"">TSP</a>]. A solution needs to be standardized. The standardization
will have to cover configuration issues, i.e., how to provision the
IPv4 capable hosts with the address of the local IPv4 tunnel servers.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Naming Requirements</span>
Naming requirements are similar to case B, with one difference: the
gateway cannot expect to use DHCPv4 to obtain the address of the DNS
resolver recommended by the ISP.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Recommendations</span>
After a careful analysis of the possible solutions, we can list a set
of recommendations for the V6OPS working group:
1. To meet case A and case C requirements, we need to develop, or
continue to develop, four types of tunneling technologies:
automatic tunnels without NAT traversal such as [<a href="#ref-6TO4" title=""Connection of IPv6 Domains via IPv4 Clouds"">6TO4</a>],
automatic tunnels with NAT traversal such as [<a href="#ref-TEREDO" title=""Teredo: Tunneling IPv6 over UDP through NATs"">TEREDO</a>],
configured tunnels without NAT traversal such as [TUNNELS,
TSP], and configured tunnels with NAT traversal.
2. To facilitate the use of configured tunnels, we need a
standardized way for hosts or gateways to discover the tunnel
server or tunnel broker that may have been configured by the
local ISP.
3. To meet case B "informal prefix sharing" requirements, we would
need a standardized way to perform "ND proxy", possibly as part
of a "multi-link subnet" specification. (The explicit prefix
delegation can be accomplished through [<a href="#ref-PREFIXDHCPV6" title=""IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6"">PREFIXDHCPV6</a>].)
4. To meet case B naming requirements, we need to proceed with the
standardization of LLMNR. (The provisioning of DNS parameters
can be accomplished through [<a href="#ref-DNSDHCPV6" title=""DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)"">DNSDHCPV6</a>].)
<span class="grey">Huitema, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
5. To meet case D IPv4 connectivity requirement, we need to
standardize an IPv4 over IPv6 tunneling mechanism, as well as
the associated configuration services.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This memo describes the general requirements for transition
mechanisms. Specific security issues should be studied and addressed
during the development of the specific mechanisms.
When hosts which have been behind a NAT are exposed to IPv6, the
security assumptions may change radically. This is mentioned in
sections <a href="#section-3.2">3.2</a> and <a href="#section-4.4">4.4</a>. One way to cope with that is to have a default
firewall with a NAT-like access configuration; however, any such
firewall configuration should allow for easy authorization of those
applications that actually need global connectivity. One might also
restrict applications which can benefit from global IPv6 connectivity
on the nodes.
Security policies should be consistent between IPv4 and IPv6. A
policy which prevents use of v6 while allowing v4 will discourage
migration to v6 without significantly improving security. Developers
and administrators should make sure that global Internet connectivity
through either IPv4 or IPv6 is restricted to only those applications
that are expressly designed for global Internet connectivity.
Several transition technologies require relays. There are concerns
that improperly designed protocols or improperly managed relays could
open new avenues for attacks against Internet services. This issue
should be addressed and mitigated in the design of the transition
technologies and in the deployment guides for relays.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Acknowledgements</span>
This memo has benefited from the comments of Margaret Wasserman,
Pekka Savola, Chirayu Patel, Tony Hain, Marc Blanchet, Ralph Droms,
Bill Sommerfeld, and Fred Templin. Tim Chown provided a lot of the
analysis for the tunneling requirements work.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-UNMANREQ">UNMANREQ</a>] Huitema, C., Austein, R., Satapati, S., and R. van der
Pol, "Unmanaged Networks IPv6 Transition Scenarios",
<a href="./rfc3750">RFC 3750</a>, April 2004.
<span class="grey">Huitema, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
[<a id="ref-IPV6">IPV6</a>] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-NEIGHBOR">NEIGHBOR</a>] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", <a href="./rfc2461">RFC 2461</a>, December
1998.
[<a id="ref-6TO4">6TO4</a>] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", <a href="./rfc3056">RFC 3056</a>, February 2001.
[<a id="ref-6TO4ANYCAST">6TO4ANYCAST</a>] Huitema, C., "An Anycast Prefix for 6to4 Relay
Routers", <a href="./rfc3068">RFC 3068</a>, June 2001.
[<a id="ref-TUNNELS">TUNNELS</a>] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", <a href="./rfc3053">RFC 3053</a>, January 2001.
[<a id="ref-DHCPV6">DHCPV6</a>] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", <a href="./rfc3315">RFC 3315</a>, July 2003.
[<a id="ref-DNSDHCPV6">DNSDHCPV6</a>] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", <a href="./rfc3646">RFC 3646</a>,
December 2003.
[<a id="ref-PREFIXDHCPV6">PREFIXDHCPV6</a>] Troan, O. and R. Droms, "IPv6 Prefix Options for
Dynamic Host Configuration Protocol (DHCP) version 6",
<a href="./rfc3633">RFC 3633</a>, December 2003.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-STUN">STUN</a>] Rosenberg, J., Weinberger, J., Huitema, C., and R.
Mahy, "STUN - Simple Traversal of User Datagram
Protocol (UDP) Through Network Address Translators
(NATs)", <a href="./rfc3489">RFC 3489</a>, March 2003.
[<a id="ref-DNSOPV6">DNSOPV6</a>] Durand, A., Ihren, J., and P. Savola. "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress.
[<a id="ref-LLMNR">LLMNR</a>] Esibov, L., Aboba, B., and D. Thaler, "Linklocal
Multicast Name Resolution (LLMNR)", Work in Progress.
[<a id="ref-TSP">TSP</a>] Blanchet, M., "IPv6 Tunnel Broker with the Tunnel
Setup Protocol(TSP)", Work in Progress.
[<a id="ref-DSTM">DSTM</a>] Bound, J., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Dual+Stack+Transition+Mechanism%22'>"Dual Stack Transition Mechanism"</a>, Work in
Progress.
<span class="grey">Huitema, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
[<a id="ref-TEREDO">TEREDO</a>] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", Work in Progress.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Authors' Addresses</span>
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: huitema@microsoft.com
Rob Austein
Internet Systems Consortium
950 Charter Street
Redwood City, CA 94063
USA
EMail: sra@isc.org
Suresh Satapati
Cisco Systems, Inc.
San Jose, CA 95134
USA
EMail: satapati@cisco.com
Ronald van der Pol
NLnet Labs
Kruislaan 419
1098 VA Amsterdam
NL
EMail: Ronald.vanderPol@nlnetlabs.nl
<span class="grey">Huitema, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3904">RFC 3904</a> Unmanaged Networks Transition Tools September 2004</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Huitema, et al. Informational [Page 19]
</pre>
|
