-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-murakami-softwire-4rd-01.txt
1064 lines (705 loc) · 43.3 KB
/
draft-murakami-softwire-4rd-01.txt
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
Internet Engineering Task Force T. Murakami
Internet-Draft IP Infusion
Intended status: Standards Track O. Troan
Expires: March 25, 2012 cisco
S. Matsushima
SoftBank
September 22, 2011
IPv4 Residual Deployment on IPv6 infrastructure - protocol specification
draft-murakami-softwire-4rd-01
Abstract
This document specifies an automatic tunneling mechanism for
providing IPv4 connectivity service to end users over a service
provider's IPv6 network. Key aspects include stateless operation,
sharing of IPv4 addresses, and an algorithmic mapping between IPv4
addresses and IPv6 tunnel endpoints.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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
Murakami, et al. Expires March 25, 2012 [Page 1]
Internet-Draft IPv4 Residual Deployment September 2011
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 4rd Configuration . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Customer Edge Configuration . . . . . . . . . . . . . . . 6
5. Algorithmic mapping . . . . . . . . . . . . . . . . . . . . . 6
5.1. Mapping Rules . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. From a CE IPv6 Prefix to a CE 4rd Prefix . . . . . . . 6
5.1.2. From a CE 4rd Prefix to a Port-set ID . . . . . . . . 7
5.1.3. From a Port-Set ID to a Port Set . . . . . . . . . . . 8
5.1.4. From an IPv4 Address or IPv4 Address + Port to a
CE IPv6 Address . . . . . . . . . . . . . . . . . . . 10
6. Encapsulation and Fragmentation Consideration . . . . . . . . 11
7. BR and CE behaviors . . . . . . . . . . . . . . . . . . . . . 12
8. NAT considerations . . . . . . . . . . . . . . . . . . . . . . 14
9. ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.1. Normative References . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Murakami, et al. Expires March 25, 2012 [Page 2]
Internet-Draft IPv4 Residual Deployment September 2011
1. Introduction
4rd is a protocol mechanism to deploy IPv4 to sites via a service
provider's (SP's) IPv6 network. Similar to Dual-Stack Lite
[I-D.ietf-softwire-dual-stack-lite], 4rd is designed to allow IPv4
traffic to be delivered over an IPv6 network without the direct
provisioning of IPv4 addresses. 4rd can provide an IPv4 prefix, an
IPv4 address or a shared IPv4 address. Like 6rd [RFC5969], 4rd is
operated in a fully stateless manner within the SP network. The
motivation for a stateless alternative to Dual-Stack Lite is
described in "Motivations for Stateless IPv4 over IPv6 Migration
Solutions" [I-D.operators-softwire-stateless-4v6-motivation].
4rd relies on IPv6 and is designed to deliver production-quality
dual-stack service while allowing IPv4 to be phased out within the SP
network. The phasing out of IPv4 within the SP network is
independent of whether the end user disables IPv4 service or not.
Further, "Greenfield" IPv6-only networks may use 4rd in order to
deliver IPv4 to sites via the IPv6 network in a way that does not
require protocol translation between IPv4 and IPv6.
4rd utilizes an algorithmic mapping between the IPv6 and IPv4
addresses that are assigned for use within the SP network. This
mapping provides automatic determination of IPv6 tunnel endpoints
from IPv4 destination addresses, allowing the stateless operation of
4rd. 4rd views the IPv6 network as a link layer for IPv4 and supports
an automatic tunneling abstraction similar to the Non-Broadcast
Multiple Access (NBMA) [RFC2491] model.
The 4rd algorithmic mapping is also used to automatically provision
IPv4 addresses and allocating a set of non-overlapping ports for each
4rd CE. The "SP-facing" (i.e., "WAN") side of the 4rd CE, operate as
native IPv6 interface with no need for IPv4 operation or support. On
the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are
implemented as for any native dual-stack service delivered by the SP.
A 4rd domain consists of 4rd Customer Edge (CE) routers and one or
more 4rd Border Relays (BRs). IPv4 packets encapsulated by 4rd
follow the IPv6 routing topology within the SP network between CEs
and among CEs and BRs. CE to CE traffic is direct, while BRs are
traversed only for IPv4 packets that are destined to or are arriving
from outside a given 4rd domain. As 4rd is stateless, BRs may be
reached using anycast for failover and resiliency.
4rd does not require any stateful NAPT [RFC3022] functions at the BRs
or elsewhere within the SP network. Instead, 4rd allows for sharing
of IPv4 addresses among multiple sites by automatically allocating a
set of non-overlapping ports for each CE as part of the stateless
Murakami, et al. Expires March 25, 2012 [Page 3]
Internet-Draft IPv4 Residual Deployment September 2011
mapping function. It is expected that the CE will, in turn, perform
local IPv4 Network Address and Port Translation (NAPT) [RFC3022]
functions for the site as is commonly performed today, except
avoiding ports outside of the allocated port set. Although 4rd is
designed primarily to support IPv4 deployment to a customer site
(such as a residential home network) by an SP, it can equally be
applied to an individual host acting as a CE router.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Terminology
4rd domain (Domain): A set of 4rd CEs and BRs connected to the same
virtual 4rd link. A service provider may
deploy 4rd with a single 4rd domain, or may
utilize multiple 4rd domains. Each domain
requires a separate 4rd prefix.
4rd Border Relay (BR): A 4rd-enabled router managed by the service
provider at the edge of a 4rd domain. A Border
Relay router has at least one of each of the
following: an IPv6-enabled interface, a 4rd
virtual interface acting as an endpoint for the
4rd IPv4 in IPv6 tunnel, and an IPv4 interface
connected to the native IPv4 network. A 4rd BR
may also be referred to simply as a "BR" within
the context of 4rd.
4rd Customer Edge (CE): A device functioning as a Customer Edge
router in a 4rd deployment. In a residential
broadband deployment, this type of device is
sometimes referred to as a "Residential
Gateway" (RG) or "Customer Premises Equipment"
(CPE). A typical 4rd CE serving a residential
site has one WAN side interface, one or more
LAN side interfaces, and a 4rd virtual
interface. A 4rd CE may also be referred to
simply as a "CE" within the context of 4rd.
Murakami, et al. Expires March 25, 2012 [Page 4]
Internet-Draft IPv4 Residual Deployment September 2011
CE IPv6 prefix: The IPv6 prefix assigned to a CE by other means
than 4rd itself, and used by 4rd to derive a CE
4rd prefix.
CE IPv6 address: In the context of 4rd, the IPv6 address used to
reach the 4rd function of a CE from other CE's
and from BR's. The IID of this address differs
from that of host interface address that start
with the CE IPv6 prefix.
CE 4rd prefix: The 4rd prefix of the CE. It is derived from
the CE IPv6 prefix by a mapping rule according
to Section 5.1. Depending on its length, it is
an IPv4 prefix, an IPv4 address, or a shared
IPv4 address followed by a Port-set ID
(Section 5.1.2).
Port-set ID: In a CE 4rd prefix longer than 32 bits, bits
that follow the first 32. It algorithmically
identifies a set of ports exclusively assigned
to the CE. As specified in Section
Section 5.1.2, the set can comprise up to 4
disjoint port ranges.
Domain IPv6 prefix: An IPv6 prefix assigned by an ISP to a 4rd
domain.
Domain IPv4 prefix: A 4rd prefix assigned by an ISP to the 4rd
domain.
IPv4 Embedded Address (EA) bits: The IPv4 EA-bits in the IPv6
address identify an IPv4 prefix, IPv4 address
or part of IPv4 address and port set.
Shared IPv4 address: An IPv4 address that is shared among multiple
nodes. Each node has a separate part of the
transport layer port space.
4. 4rd Configuration
The IPv4 prefix, IPv4 address or shared IPv4 address for use at a
customer site is created by extracting the IPv4 embedded address (EA-
bits) from the IPv6 prefix delegated to the site. Combined with the
4rd IPv4 prefix, the IPv4 prefix, IPv4 address or shared IPv4 address
is automatically created by the CE for the customer site when IPv6
service is obtained.
Murakami, et al. Expires March 25, 2012 [Page 5]
Internet-Draft IPv4 Residual Deployment September 2011
For a given 4rd domain, the BR and CE MUST be configured with a set
of mapping rules and BR IPv6 addresses. The configured values for
these elements MUST be consistent for all CEs and BRs within a given
4rd domain.
A mapping rule consist of the following elements: a Domain IPv6
prefix and prefix length, a Domain 4rd prefix and prefix length, CE
IPv6 Prefix length, and a Domain IPv6 suffix and length. See section
(Section 5.1) for a detailed description of mapping rules.
4.1. Customer Edge Configuration
The 4rd configuration elements are set to values that are the same
across all CEs within a 4rd domain. The values may be configured in
a variety of manners, including provisioning methods such as the
Broadband Forum's "TR-69" [TR069] Residential Gateway management
interface, an XML-based object retrieved after IPv6 connectivity is
established, a DNS record, an SMIv2 MIB [RFC2578], or manual
configuration by an administrator. A companion document
[I-D.mrugalski-dhc-dhcpv6-4rd]describes how to configure the
necessary parameters via IPv6 DHCP. A CE that allows IPv6
configuration by IPv6 DHCP SHOULD implement this option. Other
configuration and management methods may use the format described by
this option for consistency and convenience of implementation on CEs
that support multiple configuration methods.
The only remaining provisioning information the CE requires in order
to calculate the 4rd address and enable IPv6 connectivity is an IPv6
prefix for the CE. This CE IPv6 prefix is configured as part of
obtaining IPv6 Internet access (i.e., configured via SLAAC, DHCPv6,
DHCPv6 PD, or otherwise).
A single 4rd CE MAY be connected to more than one 4rd domain. Each
domain a given CE operates within would require its own set of 4rd
configuration elements and would generate its own 4rd address.
5. Algorithmic mapping
5.1. Mapping Rules
5.1.1. From a CE IPv6 Prefix to a CE 4rd Prefix
A 4rd mapping rule establishes a 1:1 mapping between CE IPv6 prefixes
and CE 4rd prefixes.
Murakami, et al. Expires March 25, 2012 [Page 6]
Internet-Draft IPv4 Residual Deployment September 2011
<---------------- CE IPv6 prefix (max 128) -------------->
+-------------------------------+------------------------+
| Domain IPv6 prefix | EA-bits |
+-------------------------------+------------------------+
<-- Domain IPv6 Prefix length ->:<-- EA-bits length -->:
: :
: || :
: \/ :
: :
:<-- EA-bits length -->:
+-------------------+------------------------+
| Domain 4rd prefix | EA-bits |
+-------------------+------------------------+
<----------- CE 4rd prefix (max 47) --------->
Figure 1: From a CE IPv6 Prefix to a CE 4rd Prefix
A CE derives its CE 4rd prefix from the CE IPv6 prefix, using
parameters of the applicable mapping rule. If the domain has several
mapping rules, the rule that applies is that whose Domain IPv6 prefix
has the longest match with the CE IPv6 prefix. As shown in Figure 1,
the CE 4rd prefix is created by concatenating the Domain 4rd prefix
with the IPv4 EA-bits, where the IPv4 EA-bits is the remainder of the
CE IPv6 prefix after the Domain IPv6 prefix (the length of the Domain
IPv6 prefix is defined by the mapping rule).
5.1.2. From a CE 4rd Prefix to a Port-set ID
Depending on its length, a CE 4rd prefix is either an IPv4 prefix, a
full IPv4 address, or a shared IPv4 address followed by a Port-set ID
(Figure 2). If it includes a port set ID, this ID specifies which
ports are assigned to the the CE for its exclusive use
(Section 5.1.3).
Murakami, et al. Expires March 25, 2012 [Page 7]
Internet-Draft IPv4 Residual Deployment September 2011
<-- CE 4rd prefix length -->
+--------------------------+- - -+
Shorter than 32 bits | IPv4 prefix | ... |
+ -------------------------+- - -+
<--------------- 32 ------------->
<----- CE 4rd prefix length ----->
+--------------------------------+
32 bits | IPv4 address |
+--------------------------------+
<--------------- 32 ------------->
<----------- CE 4rd prefix length ---------->
+-------------------------------+-----------+
33 to 47 bits | IPv4 shared address |Port-set ID|
+-------------------------------+-----------+
<--------------- 32 -----------><- max 15 -->
Figure 2: Variants of CE 4rd prefixes
5.1.3. From a Port-Set ID to a Port Set
The value of a Port-set ID specifies which ports can be used by a
transport layer protocol (UDP, TCP, SCTP etc). Design constraint of
the algorithm are the following:
Fairness with respect to special-value ports: No port-set must
contain any well-known ports [IANA reference].
Fairness with respect to the number of ports For a Port-set-ID's
having the same length, all sets must have the
same number of ports.
Exhaustiveness For any Port-set-ID length, the aggregate of
port sets assigned for all values must include
all ordinary-value ports.
If the Port-set ID has 1 to 12 bits, the set comprises 4 port ranges.
As shown in Figure 3, each port range is defined by its port prefix,
made of a range-specific "head" followed by the Port-set ID. Head
values are in binary 1, 01, 001, and 0001. They are chosen to
exclude ports 0-4095 and only them.
Murakami, et al. Expires March 25, 2012 [Page 8]
Internet-Draft IPv4 Residual Deployment September 2011
<------- Port (16 bits) -------->
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range a |1|x x x x x x x x| | 0xF780 - 0xF7FF
(head = 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range b |0 1|x x x x x x x x| | 0x7BC0 - 0x7BFF
(head = 01) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range c |0 0 1|x x x x x x x x| | 0x3DE0 - 0x3DFF
(head = 001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port-range d |0 0 0 1|x x x x x x x x| | 0x1EF0 - 0x1EFF
(head = 0001) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<- head-><--Port-set ID-> /\
<-- Port-range prefix --><-tail-> ||
||
Example of Port-ranges
if the Port-set ID is 0xEF
Figure 3: From Port-set ID to Port ranges
In the Port-set ID has 13 bits, only the 3 port ranges are assigned,
having heads 1, 01, and 001. If it has 14 bits, only the 2 port
ranges having heads 1 and 01 are assigned. If it has 15 bits, only
the port range having head 1 is assigned. (In these three cases, the
smallest port range has only one element).
Murakami, et al. Expires March 25, 2012 [Page 9]
Internet-Draft IPv4 Residual Deployment September 2011
5.1.4. From an IPv4 Address or IPv4 Address + Port to a CE IPv6 Address
Port-set ID
|
<--- CE 4rd prefix ---|->
+---------------+---+-|--+
|IPv4 shared address| ' |
+---------------+---+----+
<-------->
EA-bit length
: :
: || :
: || :
: \/ : Domain IPv6 suffix
: : |
+------------------+--------+--|-+----------------------------------+
|Domain IPv6 prefix| EA-bits| ' | 0 |
+------------------+--------+----+----------------------------------+
<------------ max 64 ------------>
<---------------------- CE IPv6 address (128) --------------------->
Figure 4: From 4rd Prefix to IPv6 address (shared IPv4 address case)
In order to find whether a CE IPv6 address can be derived from an
IPv4 address, or an IPv4 address + a port, a mapping rule has to be
found that matches the IPv4 information:
o If a mapping rule has a length L of CE IPv4 prefixes which does
not exceed 32 bits, there is a match if the IPv4 address starts
with the Domain 4rd prefix. The CE 4rd prefix is then the first L
bits of the IPv4 address.
o If a mapping rule has a length L of CE IPv4 prefixes which exceeds
32 bits, the match can only be found with the IPv4 address and the
port. For this, the port is examined to determine which port-
range head it starts with: 1, 01,001, or 0001. The N bits that
follow this head are taken as Port-set ID, where N is the length
of Port set ID of the mapping rule. The CE 4rd prefix is then
made of the IPv4 address followed by the Port-set ID.
If a match has been found, the CE IPv6 prefix is then made of the
Domain IPv6 prefix followed by bits of the CE 4rd prefix that follow
the Domain 4rd prefix, followed by the Domain IPv6 prefix of the
mapping rule if there is one, and followed by 0's up to 128 bits to
make a complete IPv6 address ([RFC4291]. Figure 4 illustrates this
process in the case of a shared IPv4 address.
Murakami, et al. Expires March 25, 2012 [Page 10]
Internet-Draft IPv4 Residual Deployment September 2011
6. Encapsulation and Fragmentation Consideration
Maximum transmission unit (MTU) and fragmentation issues for IPv4 in
IPv6 tunneling are discussed in detail in Section 7.2 of [RFC2473].
4rd's scope is limited to a service provider network. IPv6 Path MTU
discovery MAY be used to adjust the MTU of the tunnel as described in
Section 7.2 of [RFC2473], or the 4rd Tunnel MTU might be explicitly
configured.
The use of an anycast source address could lead to any ICMP error
message generated on the path being sent to a different BR.
Therefore, using dynamic tunnel MTU Section 7.2 of [RFC2473] is
subject to IPv6 Path MTU blackholes.
Multiple BRs using the same anycast source address could send
fragmented packets to the same 4rd CE at the same time. If the
fragmented packets from different BRs happen to use the same fragment
ID, incorrect reassembly might occur. For this reason, a BR using an
anycast source address MUST NOT fragment the IPv6 encapsulated packet
unless BR's having identical rules are required to use disjoint
ranges of fragment ID.
If the MTU is well-managed such that the IPv6 MTU on the CE WAN side
interface is set so that no fragmentation occurs within the boundary
of the SP, then the 4rd Tunnel MTU should be set to the known IPv6
MTU minus the size of the encapsulating IPv6 header (40 bytes). For
example, if the IPv6 MTU is known to be 1500 bytes, the 4rd Tunnel
MTU might be set to 1460 bytes. Absent more specific information,
the 4rd Tunnel MTU SHOULD default to 1280 bytes.
Alternatively, if BR's having identical rule are required to use
disjoint ranges of fragment ID, a BR using an anycast source address
SHOULD fragment the IPv6 encapsulated packet correctly.
For 4rd domain traversal, IPv4 packets are encapsulated in IPv6
packets whose Next header is set to 4 (i.e. IPv4). If fragmentation
of IPv6 packets is needed, it is performed according to [RFC2460].
Absent more specific information, the path MTU of a 4rd Domain has to
be set to 1280 [RFC2460].
In domains where IPv4 addresses are not shared, IPv6 destinations are
derived from IPv4 addresses alone. Thus, each IPv4 packet can be
encapsulated and decapsulated independently of each other. 4rd
processing is completely stateless.
On the other hand, in domains where IPv4 addresses are shared, BR's
and CE's can have to encapsulate IPv4 packets whose IPv6 destinations
depend on destination ports. Precautions are needed, due to the fact
Murakami, et al. Expires March 25, 2012 [Page 11]
Internet-Draft IPv4 Residual Deployment September 2011
that the destination port of a fragmented datagram is available only
in its first fragment. A sufficient precaution consists in
reassembling each datagram received in multiple packets, and to treat
it as though it would have been received in single packet. This
function is such that 4rd is in this case stateful at the IP layer.
(This is common with DS-lite and NAT64/DNS64 which, in addition, are
stateful at the transport layer.) At Domain entrance, this ensures
that all pieces of all received IPv4 datagrams go to the right IPv6
destinations.
Another peculiarity of shared IPv4 addresses is that, without
precaution, a destination could simultaneously receive from different
sources fragmented datagrams that have the same Datagram ID (the
Identification field of [RFC0791]. This would disturb the reassembly
process. To eliminate this risk, CE MUST rewrite the datagram ID to
an unique value among CEs having same shared IPv4 address upon
sending the packets over 4rd tunnel. This value SHOULD be generated
locally within the port-range assigned to a given CE. Note that
replacing a Datagram ID in an IPv4 header implies an update of its
Header-checksum fieald, by adding to it the one's complement
difference between the old and the new values.
7. BR and CE behaviors
(a) BR reception of an IPv4 packet
Step 1 BR looks up an appropriate mapping rule with a
specific Domain 4rd prefix which has the
longest match with an IPv4 destination address
in the received IPv4 packet. If the mapping
rule is not found, the received packet should
be discarded. If the length of CE 4rd prefix
associated with the mapping rule does not
exceed 32 bits, BR proceeds to step 2. If the
length of CE 4rd prefix exceeds 32 bits, BR
checks that the received packet contains a
complete IPv4 datagram. If the packet is
fragmented, BR should reassemble the packet.
Once BR can obtain the complete IPv4 datagram,
BR proceeds to step 2 as though the datagram
has been received in a single packet.
Step 2 BR generates a CE IPv6 address from the IPv4
destination address or the IPv4 destination
address and the destination port based on the
mapping rule found in step 1. If the CE IPv6
address can be successfully generated, BR
Murakami, et al. Expires March 25, 2012 [Page 12]
Internet-Draft IPv4 Residual Deployment September 2011
encapsulates the IPv4 packet in IPv6 and
forwards the IPv6 packet via the IPv6
interface. If the length of the IPv6
encapsulated packet exceeds the MTU of the IPv6
interface, the fragmentation should be done in
IPv6.
(b) BR reception of an IPv6 packet
Step 1 If the received IPv6 packet is fragmented, the
reassembly should be done in IPv6 at first.
Once BR obtains a complete IPv6 packet, BR
looks up an appropriate mapping rule with a
specific Domain 4rd prefix which has the
longest match with an IPv4 source address in
the encapsulated IPv4 packet. If the mapping
rule is not found, the received IPv6 packet
should be discarded. BR derives a CE IPv6
address from the IPv4 source address or the
IPv4 source address and the source port in the
encapsulated IPv4 packet based on the mapping
rule. If the CE IPv6 address is eqaul to the
IPv6 source address in the received IPv6
packet, BR decapsulates the IPv4 packet and
then forward it via the IPv4 interface.
(c) CE reception of an IPv4 packet
Step 1 CE looks up an appropriate mapping rule with a
specific Doamin 4rd prefix which has the
longest match with an IPv4 destination address
in the received IPv4 packet. If the mapping
rule is found, the CE 4rd prefix must be
checked. If the length does not exceeds 32
bits, CE proceeds to step 2. If the length
exceeds 32 bits, CE checks that the received
IPv4 packet contains a complete IPv4 datagram.
If the packet is fragmented, CE should
reassemble the packet. Once CE can obtain the
complete IPv4 datagram, CE proceeds to step 2
as though the datagram has been received in a
single packet. If the mapping rule is not
found, CE proceeds to step 2.
Step 2 If the mapping rule is found in step 1, CE
derives a IPv6 destination address from the
IPv4 destination address or the IPv4
destination address and the destination port
Murakami, et al. Expires March 25, 2012 [Page 13]
Internet-Draft IPv4 Residual Deployment September 2011
based on the mapping rule. If the IPv6
destination address can be derived
successfully, CE encapsulates the IPv4 packet
in IPv6 whose destination address is set to the
derived IPv6 address. If the mapping rule is
not found in step 1, CE encapsulates the IPv4
packet in IPv6 whose destination address is set
to BR IPv6 address. Then CE forwards the IPv6
packet via IPv6 interface. If the length of
the IPv6 packet exceeds the MTU of the IPv6
interface, the fragmentation should be done in
IPv6. Moreover, if using IPv4 shared address,
a Datagram ID in the received IPv4 header must
be over-written before encapsulating the IPv4
packet in IPv6. In case of shared IPv4
address, the Datagram ID must be unique among
CEs sharing the same IPv4 address. Hence, CE
should assign the unique value and set this
value to the datagram ID in IPv4 header. This
value may be generated from the port-range
assigned to the CE to keep the uniqueness among
CEs sharing same IPv4 address.
(d) CE reception of an IPv6 packet
Step 1 If the received IPv6 packet is fragmented, the
reassembly should be done in IPv6 at first.
Once CE obtains a complete IPv6 packet, CE
looks up an appropriate mapping rule with s
specific Domain 4rd prefix which has the
longest match with an IPv4 source address in
the encapsulated IPv4 packet. If the mapping
rule is found, CE derives a CE IPv6 address
from the IPv4 source address or the IPv4 source
address and the source port based on the
mapping rule and then checks that the IPv6
source address of the received IPv6 packet is
matched to it. If the mapping rule is not
found, CE checks that the IPv6 source address
is matched to BR IPv6 address. In case of
success, CE decapsulates the IPv4 packet and
forward it via the IPv4 interface.
8. NAT considerations
NAT44 should be implemented in CPE which has 4rd CE function. The
NAT44 must conform that best current practice documented in
Murakami, et al. Expires March 25, 2012 [Page 14]
Internet-Draft IPv4 Residual Deployment September 2011
[RFC4787], [RFC5508] and [RFC5382]. When there are restricted
available port numbers in a given 4rd CE described in Section 5.1.3,
the NAT44 must restrict mapping ports within the port-set.
9. ICMP
ICMP message should be supported in 4rd domain. Hence, the NAT44 in
4rd CE must implement the behavior for ICMP message conforming to the
best current practice documented in [RFC5508].
If a 4rd CE receives an ICMP message having ICMP identifier field in
ICMP header, NAT44 in the 4rd CE must rewrite this field to a
specific value assigned from the port-set described in Section 5.1.3.
BR and other CEs must handle this field similar to the port number in
tcp/udp header upon receiving the ICMP message with ICMP identifier
field.
If a 4rd BR and CE receives an ICMP error message without ICMP
identifier field for some errors that is detected inside a IPv6
tunnel, a 4rd BR and CE should replay the ICMP error message to the
original source. This behavior should be implemented conforming to
the section 8 of [RFC2473]. The 4rd BR and CE obtain the origianl
IPv6 tunnel packet storing in ICMP payload and then decapsulate IPv4
packet. Finally the 4rd BR and CE generate a new ICMP error message
from the decapsulated IPv4 packet and then forward it.
If a 4rd BR receives an ICMP error message on its IPv4 interface, the
4rd BR should replay the ICMP message to an appropriate 4rd CE. If
IPv4 address is not shared, the 4rd BR generates a CE IPv6 address
from the IPv4 destination address in the ICMP error message and
encapsulates the ICMP message in IPv6. If IPv4 address is shared,
the 4rd BR derives an original IPv4 packet from the ICMP payload and
generates a CE IPv6 address from the source address and the source
port in the original IPv4 packet. If the 4rd BR can generate the CE
IPv6 address, the 4rd BR encapsulates the ICMP error message in IPv6
and then forward it to its IPv6 interface.
10. Security Considerations
Spoofing attacks: With consistency checks between IPv4 and IPv6
sources that are performed on IPv4/IPv6 packets
received by BR's and CE's (Section 7), 4rd does
not introduce any opportunity for spoofing
attack that would not pre-exist in IPv6.
Murakami, et al. Expires March 25, 2012 [Page 15]
Internet-Draft IPv4 Residual Deployment September 2011
Denial-of-service attacks: In 4rd domains where IPv4 addresses are
shared, the fact that IPv4 datagram reassembly
may be necessary introduces an opportunity for
DOS attacks (Section 4.4). This is inherent to
address sharing, and is common with other
address sharing approaches such as DS- lite and
NAT64/DNS64. The best protection against such
attacks is to accelerate IPv6 enablement in
both clients and servers so that, where 4rd is
supported, it is less and less used.
Routing-loop attacks: This attack may exist in some automatic-
tunneling scenarios are documented in
[I-D.ietf-v6ops-tunnel-loops]. They cannot
exist with 4rd because each BRs checks that the
IPv6 source address of a received IPv6 packet
is a CE address Section 5.1.
Attacks facilitated by restricted port set: From hosts that are not
subject to ingress filtering of [RFC2827], some
attacks are possible by intervening with faked
packets during ongoing transport connections
([RFC4953], [RFC5961], [RFC6056]. The attacks
depend on guessing which ports are currently
used by target hosts. Using unrestricted port
set which mean that are IPv6 is exactly
preferable. To avoid this attacks using
restricted port set, NAT44 filtering behavior
SHOULD be "Address-Dependent Filtering".
11. IANA Consideration
This document makes no request of IANA.
12. Acknowledgements
This draft is based on original idea described in
[I-D.despres-softwire-sam]. The authors would like to thank Remi
Despres, Mark Townsley, Wojciech Dec and Olivier Vautrin.
13. References
Murakami, et al. Expires March 25, 2012 [Page 16]
Internet-Draft IPv4 Residual Deployment September 2011
13.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks",
RFC 2491, January 1999.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
13.2. Informative References
[I-D.despres-softwire-sam]
Despres, R., "Stateless Address Mapping (SAM) - a
Simplified Mesh-Softwire Model",
draft-despres-softwire-sam-01 (work in progress),
July 2010.
[I-D.ietf-softwire-dual-stack-lite]
Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", draft-ietf-softwire-dual-stack-lite-11 (work
in progress), May 2011.
[I-D.ietf-v6ops-tunnel-loops]
Nakibly, G. and F. Templin, "Routing Loop Attack using
IPv6 Automatic Tunnels: Problem Statement and Proposed
Mitigations", draft-ietf-v6ops-tunnel-loops-07 (work in
progress), May 2011.
[I-D.mrugalski-dhc-dhcpv6-4rd]
Mrugalski, T., "DHCPv6 Options for IPv4 Residual
Deployment (4rd)", draft-mrugalski-dhc-dhcpv6-4rd-00 (work
in progress), July 2011.
[I-D.operators-softwire-stateless-4v6-motivation]
Murakami, et al. Expires March 25, 2012 [Page 17]
Internet-Draft IPv4 Residual Deployment September 2011
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Stateless IPv4
over IPv6 Migration Solutions",
draft-operators-softwire-stateless-4v6-motivation-02 (work
in progress), June 2011.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT
Behavioral Requirements for ICMP", BCP 148, RFC 5508,
April 2009.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) -- Protocol Specification",
RFC 5969, August 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056,
January 2011.