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
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
|
<pre>Internet Engineering Task Force (IETF) X. Li
Request for Comments: 6219 C. Bao
Category: Informational M. Chen
ISSN: 2070-1721 H. Zhang
J. Wu
CERNET Center/Tsinghua
University
May 2011
<span class="h1">The China Education and Research Network (CERNET) IVI Translation</span>
<span class="h1">Design and Deployment for the IPv4/IPv6 Coexistence and Transition</span>
Abstract
This document presents the China Education and Research Network
(CERNET)'s IVI translation design and deployment for the IPv4/IPv6
coexistence and transition.
The IVI is a prefix-specific and stateless address mapping mechanism
for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to
an IPv6 network" scenarios. In the IVI design, subsets of the ISP's
IPv4 addresses are embedded in the ISP's IPv6 addresses, and the
hosts using these IPv6 addresses can therefore communicate with the
global IPv6 Internet directly and can communicate with the global
IPv4 Internet via stateless translators. The communications can
either be IPv6 initiated or IPv4 initiated. The IVI mechanism
supports the end-to-end address transparency and incremental
deployment. The IVI is an early design deployed in the CERNET as a
reference for the IETF standard documents on IPv4/IPv6 stateless
translation.
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/rfc6219">http://www.rfc-editor.org/info/rfc6219</a>.
<span class="grey">Li, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
Copyright Notice
Copyright (c) 2011 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-1.1">1.1</a>. Analysis of IPv4-IPv6 Translation Mechanisms ...............<a href="#page-3">3</a>
<a href="#section-1.2">1.2</a>. CERNET Translation Requirements ............................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Terms and Abbreviations .........................................<a href="#page-6">6</a>
<a href="#section-3">3</a>. The IVI Translation Algorithm ...................................<a href="#page-6">6</a>
<a href="#section-3.1">3.1</a>. Address Format .............................................<a href="#page-8">8</a>
<a href="#section-3.2">3.2</a>. Routing and Forwarding .....................................<a href="#page-9">9</a>
<a href="#section-3.3">3.3</a>. Network-Layer Header Translation ..........................<a href="#page-10">10</a>
<a href="#section-3.4">3.4</a>. Transport-Layer Header Translation ........................<a href="#page-11">11</a>
<a href="#section-3.5">3.5</a>. Fragmentation and MTU Handling ............................<a href="#page-11">11</a>
<a href="#section-3.6">3.6</a>. ICMP Handling .............................................<a href="#page-11">11</a>
<a href="#section-3.7">3.7</a>. Application Layer Gateway .................................<a href="#page-12">12</a>
<a href="#section-4">4</a>. The IVI DNS Configuration ......................................<a href="#page-12">12</a>
<a href="#section-4.1">4.1</a>. DNS Configuration for the IVI6(i) Addresses ...............<a href="#page-12">12</a>
<a href="#section-4.2">4.2</a>. DNS Service for the IVIG6(i) Addresses ....................<a href="#page-12">12</a>
<a href="#section-5">5</a>. The Advanced IVI Translation Functions .........................<a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. IVI Multicast .............................................<a href="#page-12">12</a>
<a href="#section-6">6</a>. IVI Host Operation .............................................<a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. IVI Address Assignment ....................................<a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. IPv6 Source Address Selection .............................<a href="#page-13">13</a>
<a href="#section-7">7</a>. The IVI Implementation .........................................<a href="#page-14">14</a>
<a href="#section-7.1">7.1</a>. Linux Implementation ......................................<a href="#page-14">14</a>
<a href="#section-7.2">7.2</a>. Testing Environment .......................................<a href="#page-14">14</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-14">14</a>
<a href="#section-9">9</a>. Contributors ...................................................<a href="#page-15">15</a>
<a href="#section-10">10</a>. Acknowledgments ...............................................<a href="#page-15">15</a>
<a href="#appendix-A">Appendix A</a>. The IVI Translator Configuration Example ..............<a href="#page-16">16</a>
<a href="#appendix-B">Appendix B</a>. The traceroute Results ................................<a href="#page-17">17</a>
<a href="#section-11">11</a>. References ....................................................<a href="#page-19">19</a>
<a href="#section-11.1">11.1</a>. Normative References .....................................<a href="#page-19">19</a>
<a href="#section-11.2">11.2</a>. Informative References ...................................<a href="#page-20">20</a>
<span class="grey">Li, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document presents the CERNET IVI translation design and
deployment for the IPv4/IPv6 coexistence and transition. In Roman
numerals, the "IV" stands for 4, and "VI" stands for 6, so "IVI"
stands for the IPv4/IPv6 translation.
The experiences with IPv6 deployment in the past 10 years indicate
that the ability to communicate between IPv4 and IPv6 address
families would be beneficial. However, the current transition
methods do not fully support this requirement [<a href="./rfc4213" title=""Basic Transition Mechanisms for IPv6 Hosts and Routers"">RFC4213</a>]. For
example, dual-stack hosts can communicate with both the IPv4 and IPv6
hosts, but single-stack hosts can only communicate with hosts in the
same address family. While the dual-stack approach continues to work
in many cases even in the face of IPv4 address depletion [<a href="#ref-COUNT" title=""IPv4 address countdown: http://penrose.uk6x.com/"">COUNT</a>],
there are situations where it would be desirable to communicate with
a device in another address family. Tunneling-based architectures
can link the IPv6 islands across IPv4 networks, but they cannot
provide communication between the two different address families
[<a href="./rfc3056" title=""Connection of IPv6 Domains via IPv4 Clouds"">RFC3056</a>] [<a href="./rfc5214" title=""Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)"">RFC5214</a>] [<a href="./rfc4380" title=""Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)"">RFC4380</a>]. Translation can relay communications
for hosts located in IPv4 and IPv6 networks, but the current
implementation of this kind of architecture is not scalable, and it
cannot maintain end-to-end address transparency [<a href="./rfc2766" title=""Network Address Translation - Protocol Translation (NAT-PT)"">RFC2766</a>] [<a href="./rfc3142" title=""An IPv6-to-IPv4 Transport Relay Translator"">RFC3142</a>]
[<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>] [<a href="./rfc2775" title=""Internet Transparency"">RFC2775</a>].
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Analysis of IPv4-IPv6 Translation Mechanisms</span>
Since IPv4 and IPv6 are different protocols with different addressing
structures, a translation mechanism is necessary for communication
between endpoints using different address families. There are
several ways to implement the translation. One is the Stateless IP/
ICMP Translation Algorithm (SIIT) [<a href="./rfc2765" title=""Stateless IP/ICMP Translation Algorithm (SIIT)"">RFC2765</a>], which provides a
mechanism for translation between IPv4 and IPv6 packet headers
(including ICMP headers) without requiring any per-connection state.
However, SIIT does not specify the address assignment and routing
scheme [<a href="./rfc2766" title=""Network Address Translation - Protocol Translation (NAT-PT)"">RFC2766</a>]. For example, SIIT uses IPv4-mapped IPv6 addresses
[::ffff:ipv4-addr/96] and IPv4-compatible IPv6 addresses
[::ipv4-address/96] for the address mapping, but these addresses
violate the aggregation principle of IPv6 routing [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]. The
other translation mechanism is Network Address Translation - Protocol
Translation (NAT-PT), which has serious technical and operational
difficulties; the IETF has reclassified it from Proposed Standard to
Historic status [<a href="./rfc4966" title=""Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status"">RFC4966</a>].
In order to solve the technical difficulties in NAT-PT, the issues
and the possible workarounds are:
<span class="grey">Li, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
1. NAT-PT disrupts all protocols that embed IP addresses (and/or
ports) in packet payloads. There is little that can be done
about this, other than using Application Layer Gateways (ALGs) or
preferring protocols that transport DNS names instead of
addresses.
2. Loss of end-to-end address transparency may occur. End-to-end
address transparency implies a global address space, the ability
to pass packets unaltered throughout the network, and the ability
to use source and destination addresses as unique labels
[<a href="./rfc2775" title=""Internet Transparency"">RFC2775</a>]. A reversible, algorithmic mapping can restore some of
this transparency. However, it is still not possible to ensure
that all nodes in the existing Internet support such reversible
mappings.
3. The states maintained in the translator cause scalability,
multihoming, and load-sharing problems. Hence, a stateless
translation scheme is preferred.
4. Loss of information due to incompatible semantics between IPv4
and IPv6 versions of headers and protocols may occur. A partial
remedy to this is the proper attention to the details of the
protocol translation, for example, the error-codes mapping
between ICMP and ICMPv6. However, some semantic differences
remain.
5. The DNS is tightly coupled with the translator and lack of
address mapping persistence discussed in <a href="./rfc4966#section-3.3">Section 3.3 of
[RFC4966]</a>. Hence, the DNS should be decoupled from the
translator.
6. Support for referrals is difficult in NAT-PT, given that
translated addresses may leak outside the network where these
addresses have a meaning. Stateless translation, algorithmic
address mappings, and the decoupling of DNS from the translation
process can help the handling of referrals. Nevertheless, it is
still possible that an address-based referral is passed to
someone who cannot employ it. For instance, an IPv6-only node
may pass a referral based on an IPv6 address to a node that only
understands IPv4.
<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>. CERNET Translation Requirements</span>
The China Education and Research Network has two backbones using
different address families. The CERNET is IPv4-only [<a href="#ref-CERNET" title=""CERNET Homepage: http://www.edu.cn/english_1369/index.shtml"">CERNET</a>] and
CERNET2 is IPv6-only [<a href="#ref-CNGI-CERNET2">CNGI-CERNET2</a>], which fit in "an IPv6 network to
the IPv4 Internet" and "the IPv4 Internet to an IPv6 network"
scenarios in the IETF BEHAVE working group definition [<a href="#ref-BEHAVE" title=""The IETF Behave Working Group Charter: http://datatracker.ietf.org/wg/behave/charter/"">BEHAVE</a>]
<span class="grey">Li, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
[<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>]. In order to make CERNET2 communicate with the IPv4
Internet, we designed the IVI mechanism and installed IVI translators
between the CERNET and CERNET2.
The requirements of the IVI mechanism are:
1. It should support both IPv6-initiated and IPv4-initiated
communications for the IPv6 clients/servers in "an IPv6 network".
2. It should follow current IPv4 and IPv6 routing practice without
increasing the global routing table size in both address
families.
3. It should be able to be deployed incrementally.
4. It should be able to use IPv4 addresses effectively due to the
IPv4 address depletion problem.
5. It should be stateless to achieve scalability.
6. The DNS function should be decoupled from the translator.
The specific IVI design presented in this document can satisfy the
above requirements, with the following notes:
1. It restricts the IPv6 hosts to use a subset of the addresses
inside the ISP's IPv6 block. Therefore, IPv6 autoconfiguration
cannot be used for these IPv6 hosts. Manual configuration or
autoconfiguration via stateful DHCPv6 is required.
2. It defines a one-to-one mapping between IPv4 addresses and IPv6
addresses; hence, the IPv4 addresses cannot be used efficiently.
However, the IVI6 addresses can be used both for IPv6 clients and
IPv6 servers. Due to this limitation, we suggest using IVI6
addresses for servers.
3. An ALG is still required for any applications that embed
address(es) in the payload.
4. Some issues with end-to-end transparency, address referrals, and
incompatible semantics between protocol versions still remain, as
discussed above.
The IVI is an early design deployed in the CERNET for the stateless
translation. The IETF standard IPv4-IPv6 stateless and stateful
translation mechanisms are defined in [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>], [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>],
[<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>], [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>], and [<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>].
<span class="grey">Li, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terms and Abbreviations</span>
The following terms and abbreviations are used in this document:
ISP(i): A specific Internet service provider "i".
IVIG4: The global IPv4 address space.
IPS4(i): A subset of IVIG4 allocated to ISP(i).
IVI4(i): A subset of IPS4(i); the addresses in this set will be
mapped to IPv6 via the IVI mapping mechanism and used by IPv6
hosts of ISP(i).
IPG6: The global IPv6 address space.
IPS6(i): A subset of IPG6 allocated to ISP(i).
IVIG6(i): A subset of IPS6(i), and an image of IVIG4 in the IPv6
address family via the IVI mapping mechanism. It is defined as
the IPv4-converted address in [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>].
IVI6(i): A subset of IVIG6(i) and an image of IVI4(i) in the IPv6
address family via the IVI mapping mechanism. It is defined as
the IPv4-translatable address in [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>].
IVI translator: The mapping and translation gateway between IPv4 and
IPv6 based on the IVI mechanism.
IVI DNS: Providing the IVI Domain Name System (DNS).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when
they appear 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>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. The IVI Translation Algorithm</span>
The IVI is a prefix-specific and stateless address mapping scheme
that can be carried out by individual ISPs. In the IVI design,
subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6
addresses, and the hosts using these IPv6 addresses can therefore
communicate with the global IPv6 Internet directly and can
communicate with the global IPv4 Internet via stateless translators.
The communications can either be IPv6 initiated or IPv4 initiated.
<span class="grey">Li, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
The IVI mapping and translation mechanism is implemented in an IVI
translator that connects between "an IPv6 network" and the IPv4
Internet via the ISP's IPv4 network, as shown in the following
figure.
------ ----- ------
/ The \ ----- / An \ / The \
| IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 |
\Internet/ ----- \Network/ \Internet/
------ ----- ------
<===>
Figure 1: The Scenarios: "An IPv6 Network to the IPv4 Internet" and
"the IPv4 Internet to an IPv6 Network"
In order to perform the translation function between IPv4 and IPv6
addresses, the translator needs to represent the IPv4 addresses in
IPv6 and the IPv6 addresses in IPv4.
To represent the IPv4 addresses in IPv6, a unique, prefix-specific,
and stateless mapping scheme is defined between IPv4 addresses and
subsets of IPv6 addresses, so each provider-independent IPv6 address
block (usually a /32) will have a small portion of IPv6 addresses
(for example, /40 defined by PREFIX), which is the image of the
totality of the global IPv4 addresses, as shown in the following
figure. The SUFFIX is all zeros.
+-+-+-+-+-+-+
| IVIG4 |
+-+-+-+-+-+-+
||
\ /
\/
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | IPv4 addr | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2: Representing the IPv4 Addresses in IPv6
<span class="grey">Li, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
To represent the IPv6 addresses in IPv4, each provider can borrow a
portion of its IPv4 addresses and map them into IPv6 based on the
above mapping rule. These special IPv6 addresses will be physically
used by IPv6 hosts. The original IPv4 form of the borrowed addresses
is the image of these special IPv6 addresses, and it can be accessed
by the IPv4 Internet, as shown in the following figure. The SUFFIX
can either be all zeros, or some other value for future extensions.
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PREFIX | |IVI4| | SUFFIX |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
||
\ /
\/
-+-+-+
|IVI4|
-+-+-+
Figure 3: Representing the IPv6 Addresses in IPv4
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Address Format</span>
The IVI address format is defined based on an individual ISP's IPv6
prefix, as shown in the following figure
| 0 |32 |40 |72 127|
------------------------------------------------------------------
| |ff | | |
------------------------------------------------------------------
|<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> |
Figure 4: IVI Address Mapping
where bit 0 to bit 31 are the prefix of ISP(i)'s /32 (e.g., using
document IPv6 address IPS6=2001:db8::/32) in the CERNET
implementation, bit 32 to bit 39 are all ones as the identifier of
the IVI addresses, and bit 40 to bit 71 are embedded global IPv4
space (IVIG4), presented in hexadecimal format (e.g.,
2001:db8:ff00::/40). Note that based on the IVI mapping mechanism,
an IPv4 /24 is mapped to an IPv6 /64, and an IPv4 /32 is mapped to an
IPv6 /72.
The IETF standard for the address format is defined in [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>].
<span class="grey">Li, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Routing and Forwarding</span>
Based on the IVI address mapping rule, routing is straightforward, as
shown in the following figure
/-----\ /-----\
( ISP's ) -- 192.0.2.2 ----------- 2001:db8::2 -- ( ISP's )
( IPv4 )--|R1|-------------| IVI Xlate |------------|R2|---( IPv6 )
(network) -- 192.0.2.1 ----------- 2001:db8::1 -- (network)
\-----/ \-----/
| |
| |
The IPv4 Internet The IPv6 Internet
Figure 5: IVI Routing
where
1. IVI Xlate is a special dual-stack router, with two interfaces,
one to the IPv4 network and the other to the IPv6 network (it is
also possible to have a single interface configured with both
IPv4 and IPv6 addresses). IVI Xlate can support dynamic routing
protocols in IPv4 and IPv6 address families. In the above
configuration, the static routing configuration can be used.
2. Router R1 has an IPv4 route for IVI4(i)/k (k is the prefix length
of IVI4(i)) with the next hop equal to 192.0.2.1, and this route
is distributed to the Internet with proper aggregation.
3. Router R2 has an IPv6 route for IVIG6(i)/40 with the next hop
equal to 2001:db8::1, and this route is distributed to the IPv6
Internet with proper aggregation.
4. The IVI translator has an IPv6 route for IVI6(i)/(40+k) with the
next hop equal to 2001:db8::2. The IVI translator also has an
IPv4 default route 0.0.0.0/0 with the next hop equal to
192.0.2.2.
Note that the routes described above can be learned/inserted by
dynamic routing protocols (IGP or BGP) in the IVI translator peering
with R1 and R2.
Since both IVI4(i) and IVI6(i) are aggregated to IPS4(i) and IPS6(i)
in ISP(i)'s border routers, respectively, they will not affect the
global IPv4 and IPv6 routing tables [<a href="./rfc4632" title=""Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan"">RFC4632</a>].
Since the IVI translation is stateless, it can support multihoming
when the same prefix is used for multiple translators.
<span class="grey">Li, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
Since the IVI translation can be implemented independently in each
ISP's network, it can be incrementally deployed in the global
Internet.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Network-Layer Header Translation</span>
IPv4 [<a href="./rfc0791" title=""Internet Protocol"">RFC0791</a>] and IPv6 [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] are different protocols with
different network-layer header formats; the translation of the IPv4
and IPv6 headers MUST be performed according to SIIT [<a href="./rfc2765" title=""Stateless IP/ICMP Translation Algorithm (SIIT)"">RFC2765</a>],
except for the source and destination addresses in the header, as
shown in the following figures.
-------------------------------------------------------------
IPv4 Field Translated to IPv6
-------------------------------------------------------------
Version (0x4) Version (0x6)
IHL discarded
Type of Service Traffic Class
Total Length Payload Length = Total Length - 20
Identification discarded
Flags discarded
Offset discarded
TTL Hop Limit
Protocol Next Header
Header Checksum discarded
Source Address IVI address mapping
Destination Address IVI address mapping
Options discarded
-------------------------------------------------------------
Figure 6: IPv4-to-IPv6 Header Translation
-------------------------------------------------------------
IPv6 Field Translated to IPv4 Header
-------------------------------------------------------------
Version (0x6) Version (0x4)
Traffic Class Type of Service
Flow Label discarded
Payload Length Total Length = Payload Length + 20
Next Header Protocol
Hop Limit TTL
Source Address IVI address mapping
Destination Address IVI address mapping
- IHL = 5
- Header Checksum recalculated
-------------------------------------------------------------
Figure 7: IPv6-to-IPv4 Header Translation
<span class="grey">Li, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
The IETF standard for IP/ICMP translation is defined in [<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>],
which contains updated technical specifications.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Transport-Layer Header Translation</span>
Since the TCP and UDP headers [<a href="./rfc0793" title=""Transmission Control Protocol"">RFC0793</a>] [<a href="./rfc0768" title=""User Datagram Protocol"">RFC0768</a>] consist of
checksums that include the IP header, the recalculation and updating
of the transport-layer headers MUST be performed. Note that SIIT
does not recalculate the transport-layer checksum, since checksum-
neutral IPv6 addresses are used in SIIT [<a href="./rfc2765" title=""Stateless IP/ICMP Translation Algorithm (SIIT)"">RFC2765</a>].
The IETF standard for transport-layer header translation is defined
in [<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>], which contains updated technical specifications.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Fragmentation and MTU Handling</span>
When the packet is translated by the IVI translator, due to the
different sizes of the IPv4 and IPv6 headers, the IVI6 packets will
be at least 20 bytes larger than the IVI4 packets, which may exceed
the MTU of the next link in the IPv6 network. Therefore, the MTU
handling and translation between IPv6 fragmentation headers and the
fragmentation field in the IPv4 headers are necessary; this is
performed in the IVI translator according to SIIT [<a href="./rfc2765" title=""Stateless IP/ICMP Translation Algorithm (SIIT)"">RFC2765</a>].
The IETF standard for fragmentation and MTU handling is defined in
[<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>], which contains updated technical specifications.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. ICMP Handling</span>
For ICMP message translation between IPv4 and IPv6, IVI follows the
ICMP/ICMPv6 message correspondence as defined in SIIT [<a href="./rfc2765" title=""Stateless IP/ICMP Translation Algorithm (SIIT)"">RFC2765</a>].
Note that the ICMP message may be generated by an intermediate router
whose IPv6 address does not belong to IVIG6(i). Since ICMP
translation is important to the path MTU discovery and
troubleshooting, the IPv4 representation of the non-IVIG6 addresses
in the ICMP packets is required. In the current IVI prototype, a
small IPv4 address block is used to identify the non-IVIG6 addresses.
This prevents translated ICMP messages from being discarded due to
unknown or private IP sources.
The IETF standard for IP/ICMP translation is defined in [<a href="./rfc6145" title=""IP/ICMP Translation Algorithm"">RFC6145</a>],
which contains updated technical specifications.
<span class="grey">Li, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Application Layer Gateway</span>
Due to the features of 1-to-1 address mapping and stateless
operation, IVI can support most of the existing applications, such as
HTTP, Secure SHell (SSH), and Telnet. However, some applications are
designed such that IP addresses are used to identify application-
layer entities (e.g., FTP). In these cases, an Application Layer
Gateway (ALG) is unavoidable, and it can be integrated into the IVI
translator.
The discussion of the use of ALGs is in [<a href="./rfc6144" title=""Framework for IPv4/IPv6 Translation"">RFC6144</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. The IVI DNS Configuration</span>
The DNS [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>] service is important for the IVI mechanism.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. DNS Configuration for the IVI6(i) Addresses</span>
For providing authoritative DNS service for IVI4(i) and IVI6(i), each
host name will have both an A record and a AAAA record pointing to
IVI4(i) and IVI6(i), respectively. Note that the same name always
points to a unique host, which is an IVI6(i) host, and it has IVI4(i)
representation via the IVI translator.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. DNS Service for the IVIG6(i) Addresses</span>
For resolving the IPv6 form of the global IPv4 space (IVIG6(i)), each
ISP must provide customized IVI DNS service for the IVI6(i) hosts.
The IVI DNS server MUST be deployed in a dual-stack environment.
When the IVI6(i) host queries a AAAA record for an IPv4-only domain
name, the IVI DNS will query the AAAA record first. If the AAAA
record does not exist, the IVI DNS will query the A record and map it
to IVIG6(i), and return a AAAA record to the IVI6(i) host. The
technical specifications for this process are defined in [<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. The Advanced IVI Translation Functions</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. IVI Multicast</span>
The IVI mechanism can support IPv4/IPv6 communication of Protocol
Independent Multicast - Source-Specific Multicast (PIM-SSM) [<a href="./rfc5771" title=""IANA Guidelines for IPv4 Multicast Address Assignments"">RFC5771</a>]
[<a href="./rfc3569" title=""An Overview of Source-Specific Multicast (SSM)"">RFC3569</a>] [<a href="./rfc4607" title=""Source-Specific Multicast for IP"">RFC4607</a>].
There will be 2^24 group addresses for IPv4 SSM. The corresponding
IPv6 SSM group addresses can be defined as shown in the following
figure.
<span class="grey">Li, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
-------------------------------------------------------
IPv4 Group Address IPv6 Group Address
-------------------------------------------------------
232.0.0.0/8 ff3e:0:0:0:0:0:f000:0000/96
232.255.255.255/8 ff3e:0:0:0:0:0:f0ff:ffff/96
-------------------------------------------------------
Figure 8: IVI Multicast Group Address Mapping
The source address in IPv6 MUST be IVI6(i) in order to perform
Reverse Path Forwarding (RPF) as required by PIM - Sparse Mode
(PIM-SM).
The interoperation of PIM-SM for IPv4 and IPv6 address families can
either be implemented via an Application Layer Gateway or via static
joins based on IGMPv3 and Multicast Listener Discovery Version 2
(MLDv2) in IPv4 and IPv6, respectively.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IVI Host Operation</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. IVI Address Assignment</span>
The IVI6 address has a special format (for example, IVI4=192.0.2.1/32
and IVI6=2001:db8:ffc0:2:100::/72); therefore, stateless IPv6 address
autoconfiguration cannot be used. However, the IVI6 can be assigned
to the IPv6 end system via manual configuration or stateful
autoconfiguration via DHCPv6.
o For the manual configuration, the host needs to configure the IVI6
address and the corresponding prefix length, as well as the
default gateway address and the DNS resolver address.
o For the DHCPv6 configuration, the DHCPv6 will assign the IVI6
address and the DNS resolver address to the host. The router in
the subnet should enable router advertisement (RA), since the
default gateway is learned from the router.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. IPv6 Source Address Selection</span>
Since each IPv6 host may have multiple addresses, it is important for
the host to use an IVI6(i) address to reach the global IPv4 networks.
The short-term workaround is to use IVI6(i) as the default source
IPv6 address of the host, defined as the policy table in [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>].
The long-term solution requires that the application should be able
to select the source addresses for different services.
<span class="grey">Li, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. The IVI Implementation</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Linux Implementation</span>
An implementation of IVI exists for the Linux operating system. The
source code can be downloaded from [<a href="#ref-LINUX" title=""Source Code of the IVI implementation for Linux: http://linux.ivi2.org/impl/"">LINUX</a>]. An example of how to
configure an IVI deployment is shown in <a href="#appendix-A">Appendix A</a>.
The IVI DNS source code for the IVIG6(i) addresses presented in this
document can be downloaded from [<a href="#ref-DNS" title=""Source Code of the IVI DNS http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/"">DNS</a>].
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Testing Environment</span>
The IVI translator based on the Linux implementation has been
deployed between [<a href="#ref-CERNET" title=""CERNET Homepage: http://www.edu.cn/english_1369/index.shtml"">CERNET</a>] (IPv4-only) and [<a href="#ref-CNGI-CERNET2">CNGI-CERNET2</a>] (IPv6-only)
since March 2006. The pure-IPv6 web servers using IVI6 addresses
[2001:250:ffca:2672:100::] behind the IVI translator can be accessed
by the IPv4 hosts [<a href="#ref-TEST4" title="">TEST4</a>], and also by the global IPv6 hosts [<a href="#ref-TEST6" title="">TEST6</a>].
The pure-IPv6 clients using IVI6 addresses behind the IVI translator
can access IPv4 servers on the IPv4 Internet.
Two traceroute results are presented in <a href="#appendix-B">Appendix B</a> to show the
address mapping of the IVI mechanism.
IVI6 manual configuration and DHCPv6 configuration of the IPv6 end
system have also been tested with success.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
This document presents the prefix-specific and stateless address
mapping mechanism (IVI) for the IPv4/IPv6 coexistence and transition.
The IPv4 security and IPv6 security issues should be addressed by
related documents of each address family and are not included in this
document.
However, there are several issues that need special considerations,
specifically (a) IPsec and its NAT traversal, (b) DNS Security
Extensions (DNSSEC), and (c) firewall filter rules.
o IPsec and its NAT traversal: Since the IVI scheme maintains end-
to-end address transparency, IPsec could work with or without NAT
traversal techniques.
o DNSSEC: DNSSEC verification will be terminated at the IVI DNS for
the "A record to AAAA record" translation. It would be fine to
have a translation in a local IVI DNS server that also verifies
<span class="grey">Li, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
DNSSEC, or in the host, if the host both translates the DNS entry
and again verifies DNSSEC validity. The DNSSEC discussion is in
[<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>].
o Firewall filter rules: Since the IVI scheme maintains the end-to-
end address transparency and there is a unique mapping between
IPv4 and IPv6 addresses, the firewall filter rule can therefore be
implemented for one address family, or mapped to another address
family and implemented in that address family. However, the
current IPv6 routers may only support the access-list or uRPF
(unicast Reverse Path Forwarding) for the prefix length shorter
than /64; there may a practical constraint for the construction of
such rules.
Except for the issues discussed above, we have not found special
security problems introduced by the IVI translation in our
experiments.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Contributors</span>
The authors would like to acknowledge the following contributors in
the different phases of the IVI development: Ang Li, Yuncheng Zhu,
Junxiu Lu, Yu Zhai, Wentao Shang, Weifeng Jiang, and Bizheng Fu.
The authors would like to acknowledge the following contributors, who
provided helpful inputs concerning the IVI concept: Bill Manning,
David Ward, Elwyn Davies, Lixia Zhang, Jun Murai, Fred Baker, Jari
Arkko, Ralph Droms, Tony Hain, and Kevin Yin.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>
The authors thank the following for funding support: the CERNET,
CNGI-CERNET2, CNGI Research and Development, and the China "863" and
China "973" projects.
<span class="grey">Li, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. The IVI Translator Configuration Example</span>
#!/bin/bash
# open forwarding
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding
# config route for IVI6 = 2001:db8:ffc0:2:0::/64,
# IVI4 = 192.0.2.0/24
# configure IPv6 route
route add -A inet6 2001:db8:ffc0:2:0::/64 \
gw 2001:da8:aaae::206 dev eth0
# config mapping for source-PF = 2001:db8::/32
# config mapping for destination-PF = 2001:db8::/32
# for each mapping, a unique pseudo-address (10.0.0.x/8)
# should be configured.
# ip addr add 10.0.0.1/8 dev eth0
# IPv4-to-IPv6 mapping: multiple mappings can be done via multiple
# commands.
# mroute IVI4-network IVI4-mask pseudo-address interface \
# source-PF destination-PF
/root/mroute 192.0.2.0 255.255.255.0 10.0.0.1 \
eth0 2001:db8:: 2001:db8::
# IPv6-to-IPv4 mapping
# mroute6 destination-PF destination-PF-pref-len
/root/mroute6 2001:db8:ff00:: 40
Figure 9: IVI Configuration Example
<span class="grey">Li, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. The traceroute Results</span>
ivitraceroute 202.38.108.2
1 202.112.0.65 6 ms 2 ms 1 ms
2 202.112.53.73 4 ms 6 ms 12 ms
3 202.112.53.178 1 ms 1 ms 1 ms
4 202.112.61.242 1 ms 1 ms 1 ms
5 192.0.2.100 1 ms 1 ms 1 ms
6 192.0.2.102 1 ms 1 ms 1 ms
7 192.0.2.103 2 ms 2 ms 2 ms
8 192.0.2.104 2 ms 2 ms 2 ms
9 192.0.2.105 4 ms 4 ms 3 ms
10 202.38.108.2 2 ms 3 ms 3 ms
Figure 10: ivitraceroute Results
Note that the non-IVIG6 addresses are mapped to IPv4 document address
192.0.2.0/24.
<span class="grey">Li, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
ivitraceroute6 www.mit.edu
src_ivi4=202.38.97.205 src_ivi6=2001:da8:ffca:2661:cd00::
dst_host=www.mit.edu
dst_ip4=18.7.22.83 dst_ivig=2001:da8:ff12:716:5300::
traceroute to 2001:da8:ff12:716:5300:: (2001:da8:ff12:716:5300::),
30 hops max, 40 byte packets to not_ivi
1 2001:da8:ff0a:0:100:: 0.304 ms 0.262 ms 0.190 ms
10.0.0.1
2 2001:da8:ffca:7023:fe00:: 0.589 ms * *
202.112.35.254
3 2001:da8:ffca:7035:4900:: 1.660 ms 1.538 ms 1.905 ms
202.112.53.73
4 2001:da8:ffca:703d:9e00:: 0.371 ms 0.530 ms 0.459 ms
202.112.61.158
5 2001:da8:ffca:7035:1200:: 0.776 ms 0.704 ms 0.690 ms
202.112.53.18
6 2001:da8:ffcb:b5c2:7d00:: 89.382 ms 89.076 ms 89.240 ms
203.181.194.125
7 2001:da8:ffc0:cb74:9100:: 204.623 ms 204.685 ms 204.494 ms
192.203.116.145
8 2001:da8:ffcf:e7f0:8300:: 249.842 ms 249.945 ms 250.329 ms
207.231.240.131
9 2001:da8:ff40:391c:2d00:: 249.891 ms 249.936 ms 250.090 ms
64.57.28.45
10 2001:da8:ff40:391c:2a00:: 259.030 ms 259.110 ms 259.086 ms
64.57.28.42
11 2001:da8:ff40:391c:700:: 264.247 ms 264.399 ms 264.364 ms
64.57.28.7
12 2001:da8:ff40:391c:a00:: 271.014 ms 269.572 ms 269.692 ms
64.57.28.10
13 2001:da8:ffc0:559:dd00:: 274.300 ms 274.483 ms 274.316 ms
192.5.89.221
14 2001:da8:ffc0:559:ed00:: 274.534 ms 274.367 ms 274.517 ms
192.5.89.237
15 * * *
16 2001:da8:ff12:a800:1900:: 276.032 ms 275.876 ms 276.090 ms
18.168.0.25
17 2001:da8:ff12:716:5300:: 276.285 ms 276.370 ms 276.214 ms
18.7.22.83
Figure 11: ivitraceroute6 Results
Note that all of the IPv4 addresses can be mapped to prefix-specific
IPv6 addresses (for example, 18.7.22.83 is mapped to 2001:da8:ff12:
716:5300::).
<span class="grey">Li, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>
<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>
[<a id="ref-RFC0768">RFC0768</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
August 1980.
[<a id="ref-RFC0791">RFC0791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-RFC0793">RFC0793</a>] Postel, J., "Transmission Control Protocol", STD 7,
<a href="./rfc793">RFC 793</a>, September 1981.
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<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>, March 1997.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-RFC2765">RFC2765</a>] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", <a href="./rfc2765">RFC 2765</a>, February 2000.
[<a id="ref-RFC2766">RFC2766</a>] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", <a href="./rfc2766">RFC 2766</a>,
February 2000.
[<a id="ref-RFC3056">RFC3056</a>] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", <a href="./rfc3056">RFC 3056</a>, February 2001.
[<a id="ref-RFC4213">RFC4213</a>] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>, October 2005.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-RFC4380">RFC4380</a>] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", <a href="./rfc4380">RFC 4380</a>,
February 2006.
[<a id="ref-RFC4607">RFC4607</a>] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", <a href="./rfc4607">RFC 4607</a>, August 2006.
[<a id="ref-RFC4632">RFC4632</a>] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", <a href="https://www.rfc-editor.org/bcp/bcp122">BCP 122</a>, <a href="./rfc4632">RFC 4632</a>, August 2006.
<span class="grey">Li, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
[<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>,
March 2008.
[<a id="ref-RFC5771">RFC5771</a>] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for
IPv4 Multicast Address Assignments", <a href="https://www.rfc-editor.org/bcp/bcp51">BCP 51</a>, <a href="./rfc5771">RFC 5771</a>,
March 2010.
[<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>,
October 2010.
[<a id="ref-RFC6144">RFC6144</a>] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", <a href="./rfc6144">RFC 6144</a>, April 2011.
[<a id="ref-RFC6145">RFC6145</a>] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", <a href="./rfc6145">RFC 6145</a>, April 2011.
[<a id="ref-RFC6146">RFC6146</a>] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", <a href="./rfc6146">RFC 6146</a>, April 2011.
[<a id="ref-RFC6147">RFC6147</a>] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", <a href="./rfc6147">RFC 6147</a>,
April 2011.
<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>
[<a id="ref-BEHAVE">BEHAVE</a>] "The IETF Behave Working Group Charter:
<a href="http://datatracker.ietf.org/wg/behave/charter/">http://datatracker.ietf.org/wg/behave/charter/</a>".
[<a id="ref-CERNET">CERNET</a>] "CERNET Homepage:
<a href="http://www.edu.cn/english_1369/index.shtml">http://www.edu.cn/english_1369/index.shtml</a>".
[<a id="ref-CNGI-CERNET2">CNGI-CERNET2</a>]
"CNGI-CERNET2 Homepage:
<a href="http://www.cernet2.edu.cn/index_en.htm">http://www.cernet2.edu.cn/index_en.htm</a>".
[<a id="ref-COUNT">COUNT</a>] "IPv4 address countdown: <a href="http://penrose.uk6x.com/">http://penrose.uk6x.com/</a>".
[<a id="ref-DNS">DNS</a>] "Source Code of the IVI DNS
<a href="http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/">http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/</a>".
[<a id="ref-LINUX">LINUX</a>] "Source Code of the IVI implementation for Linux:
<a href="http://linux.ivi2.org/impl/">http://linux.ivi2.org/impl/</a>".
<span class="grey">Li, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
[<a id="ref-RFC2775">RFC2775</a>] Carpenter, B., "Internet Transparency", <a href="./rfc2775">RFC 2775</a>,
February 2000.
[<a id="ref-RFC3142">RFC3142</a>] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport
Relay Translator", <a href="./rfc3142">RFC 3142</a>, June 2001.
[<a id="ref-RFC3484">RFC3484</a>] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.
[<a id="ref-RFC3569">RFC3569</a>] Bhattacharyya, S., Ed., "An Overview of Source-Specific
Multicast (SSM)", <a href="./rfc3569">RFC 3569</a>, July 2003.
[<a id="ref-RFC4966">RFC4966</a>] Aoun, C. and E. Davies, "Reasons to Move the Network
Address Translator - Protocol Translator (NAT-PT) to
Historic Status", <a href="./rfc4966">RFC 4966</a>, July 2007.
[<a id="ref-TEST4">TEST4</a>] "Test homepage for the IVI4(i): <a href="http://test4.ivi2.org">http://test4.ivi2.org</a>".
[<a id="ref-TEST6">TEST6</a>] "Test homepage for the IVI6(i): <a href="http://test6.ivi2.org">http://test6.ivi2.org</a>",
Available using IPv6 only.
<span class="grey">Li, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6219">RFC 6219</a> CERNET IVI Translation Design May 2011</span>
Authors' Addresses
Xing Li
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
EMail: xing@cernet.edu.cn
Congxiao Bao
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
EMail: congxiao@cernet.edu.cn
Maoke Chen
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
EMail: fibrib@gmail.com
Hong Zhang
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
EMail: neilzh@gmail.com
Jianping Wu
CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University
Beijing 100084
CN
Phone: +86 10-62785983
EMail: jianping@cernet.edu.cn
Li, et al. Informational [Page 22]
</pre>
|
