367:
The first "4rd" specification, unlike the current one of RFC 7600, used IPv4 encapsulation in IPv6 packets, the only known tunneling approach at that time to ensure complete IPv4 preservation across IPv6-only domains. It was the first proposal that combined stateless address mapping, mesh topology,
417:
The other was based on discovery that, as mentioned above, an upgraded IPv4-IPv6 double translation algorithm was possible that combined applicability of IPv6 packet inspections to IPv4, like MAP-T, and full compatibility with IPv4 fragmentation like MAP-E. As the "4rd" acronym was no longer used
333:
to all its customers of this domain, it can choose any of MAP-E, MAP-T, or 4rd, with due awareness that MAP-E and MAP-T are specified in standards-track RFCs, while 4rd is, at least so far, specified in an experimental-track RFC (see the
History section below): the chosen mechanism remains purely
358:
Another issue about which the 4rd specification goes beyond those of MAP-E and MAP-T concerns fragmented IPv4 datagrams. In MAP-E and MAP-T specifications, the only fully described behaviors involves datagram reassembly at domain entry before forwarding. In order to improve user-perceived
346:
at Domain
Entries and Exits. This is possible because IPv6 packet headers, duly complemented with their Fragment headers whenever needed, are large enough to encode in them, in an ad hoc way detailed in RFC 7600, all useful IPv4-header information. (This was not possible in
414:. The idea was that, to satisfy the standard unicity objective, a specification having two variants (among which a choice remains needed for each IPv6-only domain), might be considered as equivalent to a single standard. But no consensus was reached on this interpretation.
303:
Applicability of IPv6 packet inspections to IPv4: when traversing IPv6-only domains, converted IPv4 packets are ordinary IPv6 packets, with their contents unchanged and valid in IPv6. Thus, IPv6 filters that are performed within the IPv6-only domain, e.g. for
431:
Finally, in
December 2014 the Softwire working group changed its previous decision, and decided to put MAP-T on Standards Track in parallel with MAP-E, provided a note in the MAP-T RFC would signal its incompatibility with the
354:
IP-layer options of IPv4 are not supported in 4rd, but without practical consequence because end systems are already adapted to the fact that, for security reasons, IPv4 IP-layer options are filtered by many routers.
268:
Shared IPv4 addresses: to deal with the unavoidable IPv4-address shortage, several customers can be assigned a common IPv4 address, with disjoint TCP/UDP port sets assigned to each (an application of the general
359:
performance, to reduce domain-entry processing, and to reduce attack opportunities, the 4rd specification includes an algorithm whereby received fragments of large datagrams are forwarded one by one on the fly.
288:-specified mechanisms having the same main features, i.e., MAP-E (RFC 7597, RFC 7598, RFC 2473) and MAP-T (RFC 7599, RFC 7598, RFC 6145), its distinctive property is that it simultaneously supports:
424:. A proposal to take this approach for a unique standard was made. But, despite a validation of its principle on an implementation, did not raise interest from supporters of either MAP-E, or MAP-T.
383:
one-way translations of RFC 2765. Compared to encapsulation, it had the advantage of making IPv6 packet inspections applicable to translated UDP and TCP IPv4 packets, but, due to limitations of
428:
After a long debate, the
Softwire working group decided, in August 2012, that MAP-E alone would be standardized, and that work could continue on both 4rd and MAP-T, but only as experimental.
394:
In this context, approval of one of the two designs as single standard seemed out of reach, despite the general wish for standard unicity. Two different directions were then taken.
217:
379:
approach was next proposed, called dIVI. Instead of encapsulation, it used two successive translations (from IPv4 to IPv6 and then conversely), based on the existing
296:
of RFC 4821, recommended in RFC 6349, is preserved. Without it, wherever firewalls filter ICMP packets, end systems that support RFC 4821 lose their ability to
471:
model implies the attribution of four contiguous port ranges to different customers for each IPv4 address. Free was also known to be the first implementer of
210:
276:
Stateless operation: conversions of IPv4 packets into IPv6 packets at domain entry, and the reverse at domain exit, are stateless (i.e., one where
538:
976:
351:, the tunneling mechanism for IPv6 across IPv4-only domains, because IPv4 headers are too small to contain all IPv6-header information).
203:
942:
342:
The key that permits to combine IPv4-fragmentation transparency with IPv6 deep packet
Inspection in a single design is the use of a
285:
403:
384:
380:
645:
Dec, W.; Li, X.; Bao, C.; Matsushima, S.; Murakami, T.; Murakami, T.; Taylor, T. (2015). Troan, O.; Taylor, T. (eds.).
448:
330:
87:
249:(IPv6), while maintaining IPv4 service to customers. The protocol and sample applications are specified in RFC 7600.
444:
326:
242:
191:
186:
134:
82:
72:
53:
238:
139:
19:
387:, lacked full compatibility with IPv4 fragmentation (and consequently, as mentioned above, compatibility with
868:
742:
314:
764:
710:
664:
618:
572:
511:
348:
103:
58:
927:
896:
306:
791:
747:
882:
433:
388:
293:
38:
691:
Li, X.; Bao, C.; Troan, O.; Matsushima, S.; Murakami, T.; Murakami, T. (2015). Dec, W. (ed.).
468:
376:
369:
270:
752:
696:
650:
604:
560:
497:
170:
77:
809:
777:
723:
677:
631:
585:
524:
447:' possibility to deploy it, for its functional advantages, in domains where they provide
129:
845:
827:
737:
Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (ed.).
555:
Despres, R.; Penno, R.; Lee, Y.; Chen, G.; Chen, M.; Chen, M. (2015). Jiang, S. (ed.).
464:
970:
810:"IPv4 Residual Deployment across IPv6-Service networks (4rd) ISP-NAT's made optional"
144:
124:
913:
692:
600:
493:
318:, are, implicitly and automatically, effective on domain-traversing IPv4 packets.
467:
in "lesser-dense areas", starting from
December 2015. The implementation of the
738:
646:
556:
460:
329:
wants to offer residual IPv4 service across an IPv6-only domain, and provides
310:
539:"Does Linux have an Equivalent of Windows PMTU Blackhole Router Discovery?"
947:
292:
Full IPv4-fragmentation transparency: with this feature, support of the
792:"Public IPv4 addresses and IPv4E prefixes across IPv6-only Domains 4rd"
756:
701:
655:
609:
564:
502:
149:
48:
322:
MAP-E only supports the former, and MAP-T only supports the latter.
647:"Receiving IPv4 Fragments on the MAP domain borders (MAP-E case )"
261:
Mesh topology: between two endpoints, IPv4 packets take the same
165:
68:
693:"Receiving IPv4 Fragments on the MAP domain borders (MAP-T case)"
246:
63:
43:
33:
739:"Ports of Fragments Addressed to Shared-Address CEs (4rd case)"
472:
410:, and to associate them into a combined specification named
943:"Free peut attribuer la même adresse IP à plusieurs abonnés"
557:"Reversible Packet Translations at Domain Entries and Exits"
398:
One proposed to rename the 4rd encapsulation solution as
550:
548:
418:
for the encapsulation solution, this solution was named
463:
is deemed to have deployed 4rd for its experiment of
298:take advantage of paths that support large packets
257:IPv4 Residual Deployment has three main features:
928:"[Softwires] MAP-T to Standards Track"
492:Wu, J.; Cui, Y.; Metz, C.; Rosen, E. (2009).
443:alone in the Experimental category (yet with
211:
8:
908:
906:
599:Dugal, D.; Pignataro, C.; Dunn, R. (2011).
863:
861:
859:
218:
204:
15:
914:"IETF Softwires (softwire) Working Group"
869:"IETF-84 - Softwire WG - Meeting minutes"
746:
700:
654:
608:
501:
941:Champeau, Guillaume (15 February 2016).
484:
178:
157:
116:
95:
25:
18:
773:
762:
719:
708:
673:
662:
627:
616:
581:
570:
520:
509:
7:
14:
601:"Design Trade-Offs - in RFC 6192"
280:is needed in domain edge nodes).
494:"IPv4-over-IPv6 mesh scenario"
1:
344:reversible packet translation
977:IPv6 transition technologies
883:"draft-ietf-softwire-map-00"
846:"draft-ietf-softwire-map-00"
897:"4rd Implementation Report"
449:customer premises equipment
331:customer-premises equipment
247:Internet Protocol version 6
993:
828:"draft-xli-behave-divi-02"
391:recommended in RFC 6349).
243:Internet service providers
20:IPv6 transition mechanisms
451:to all their customers).
334:internal to each domain.
239:IPv6 transition mechanism
231:IPv4 Residual Deployment
402:, to rename the double
375:Another stateless-mesh-
315:Deep packet inspections
772:Cite journal requires
718:Cite journal requires
672:Cite journal requires
626:Cite journal requires
580:Cite journal requires
519:Cite journal requires
455:Real-world deployment
278:no per-customer state
307:Access Control Lists
273:model of RFC 6346).
434:path MTU Discovery
389:path MTU Discovery
294:path MTU Discovery
284:Compared to other
245:for deployment of
39:Lightweight 4over6
228:
227:
984:
961:
960:
958:
956:
938:
932:
931:
924:
918:
917:
910:
901:
900:
893:
887:
886:
879:
873:
872:
865:
854:
853:
850:Ietf Datatracker
842:
836:
835:
832:Ietf Datatracker
824:
818:
817:
814:Ietf Datatracker
806:
800:
799:
796:Ietf Datatracker
788:
782:
781:
775:
770:
768:
760:
757:10.17487/RFC7600
750:
734:
728:
727:
721:
716:
714:
706:
704:
702:10.17487/RFC7599
688:
682:
681:
675:
670:
668:
660:
658:
656:10.17487/RFC7597
642:
636:
635:
629:
624:
622:
614:
612:
610:10.17487/RFC6192
596:
590:
589:
583:
578:
576:
568:
565:10.17487/RFC7600
552:
543:
542:
535:
529:
528:
522:
517:
515:
507:
505:
503:10.17487/RFC5565
489:
265:as IPv6 packets.
220:
213:
206:
16:
992:
991:
987:
986:
985:
983:
982:
981:
967:
966:
965:
964:
954:
952:
940:
939:
935:
926:
925:
921:
912:
911:
904:
895:
894:
890:
881:
880:
876:
867:
866:
857:
844:
843:
839:
826:
825:
821:
808:
807:
803:
790:
789:
785:
771:
761:
748:10.1.1.697.6541
736:
735:
731:
717:
707:
690:
689:
685:
671:
661:
644:
643:
639:
625:
615:
598:
597:
593:
579:
569:
554:
553:
546:
537:
536:
532:
518:
508:
491:
490:
486:
481:
459:The French ISP
457:
406:translation as
365:
340:
255:
224:
26:Standards Track
12:
11:
5:
990:
988:
980:
979:
969:
968:
963:
962:
933:
919:
902:
888:
874:
855:
837:
819:
801:
783:
774:|journal=
729:
720:|journal=
683:
674:|journal=
637:
628:|journal=
591:
582:|journal=
544:
530:
521:|journal=
483:
482:
480:
477:
456:
453:
426:
425:
415:
364:
361:
339:
336:
320:
319:
301:
282:
281:
274:
266:
254:
251:
226:
225:
223:
222:
215:
208:
200:
197:
196:
195:
194:
189:
181:
180:
176:
175:
174:
173:
168:
160:
159:
155:
154:
153:
152:
147:
142:
137:
132:
127:
119:
118:
114:
113:
112:
111:
106:
98:
97:
93:
92:
91:
90:
85:
80:
75:
66:
61:
56:
51:
46:
41:
36:
28:
27:
23:
22:
13:
10:
9:
6:
4:
3:
2:
989:
978:
975:
974:
972:
950:
949:
944:
937:
934:
929:
923:
920:
915:
909:
907:
903:
898:
892:
889:
884:
878:
875:
870:
864:
862:
860:
856:
851:
847:
841:
838:
833:
829:
823:
820:
815:
811:
805:
802:
797:
793:
787:
784:
779:
766:
758:
754:
749:
744:
740:
733:
730:
725:
712:
703:
698:
694:
687:
684:
679:
666:
657:
652:
648:
641:
638:
633:
620:
611:
606:
602:
595:
592:
587:
574:
566:
562:
558:
551:
549:
545:
540:
534:
531:
526:
513:
504:
499:
495:
488:
485:
478:
476:
474:
470:
466:
462:
454:
452:
450:
446:
442:
437:
436:of RFC 4821.
435:
429:
423:
422:
416:
413:
409:
405:
401:
397:
396:
395:
392:
390:
386:
382:
378:
373:
371:
362:
360:
356:
352:
350:
345:
337:
335:
332:
328:
323:
317:
316:
312:
308:
302:
299:
295:
291:
290:
289:
287:
279:
275:
272:
267:
264:
263:direct routes
260:
259:
258:
252:
250:
248:
244:
240:
236:
232:
221:
216:
214:
209:
207:
202:
201:
199:
198:
193:
190:
188:
185:
184:
183:
182:
177:
172:
169:
167:
164:
163:
162:
161:
156:
151:
148:
146:
145:Public 4over6
143:
141:
138:
136:
133:
131:
128:
126:
125:Tunnel broker
123:
122:
121:
120:
117:Informational
115:
110:
107:
105:
102:
101:
100:
99:
94:
89:
86:
84:
81:
79:
76:
74:
70:
67:
65:
62:
60:
57:
55:
52:
50:
47:
45:
42:
40:
37:
35:
32:
31:
30:
29:
24:
21:
17:
953:. Retrieved
946:
936:
922:
891:
877:
849:
840:
831:
822:
813:
804:
795:
786:
765:cite journal
732:
711:cite journal
686:
665:cite journal
640:
619:cite journal
594:
573:cite journal
533:
512:cite journal
487:
458:
440:
438:
430:
427:
420:
419:
411:
407:
399:
393:
374:
366:
357:
353:
343:
341:
324:
321:
305:
297:
283:
277:
262:
256:
234:
230:
229:
108:
96:Experimental
955:29 February
951:(in French)
479:References
439:This left
338:Principles
311:Web caches
179:Deprecated
743:CiteSeerX
971:Category
948:Numerama
253:Features
237:) is an
363:History
192:NAPT-PT
140:464XLAT
54:DS-Lite
745:
325:If an
187:NAT-PT
158:Drafts
150:ISATAP
78:Teredo
49:6over4
408:MAP-T
400:MAP-E
166:AYIYA
73:DNS64
69:NAT64
957:2016
778:help
724:help
678:help
632:help
586:help
525:help
465:FTTH
461:Free
445:ISPs
404:SIIT
385:SIIT
381:SIIT
368:and
286:IETF
241:for
171:dIVI
83:SIIT
64:6to4
44:6in4
34:4in6
753:doi
697:doi
651:doi
605:doi
561:doi
498:doi
473:6rd
469:A+P
441:4rd
421:4rd
412:MAP
377:A+P
370:A+P
349:6rd
327:ISP
271:A+P
235:4rd
135:TRT
130:IVI
109:4rd
104:TSP
88:MAP
59:6rd
973::
945:.
905:^
858:^
848:.
830:.
812:.
794:.
769::
767:}}
763:{{
751:.
741:.
715::
713:}}
709:{{
695:.
669::
667:}}
663:{{
649:.
623::
621:}}
617:{{
603:.
577::
575:}}
571:{{
559:.
547:^
516::
514:}}
510:{{
496:.
475:.
372:.
313:,
309:,
71:/
959:.
930:.
916:.
899:.
885:.
871:.
852:.
834:.
816:.
798:.
780:)
776:(
759:.
755::
726:)
722:(
705:.
699::
680:)
676:(
659:.
653::
634:)
630:(
613:.
607::
588:)
584:(
567:.
563::
541:.
527:)
523:(
506:.
500::
300:.
233:(
219:e
212:t
205:v
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.