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
|
<pre>Independent Submission J. Wu
Request for Comments: 5747 Y. Cui
Category: Experimental X. Li
ISSN: 2070-1721 M. Xu
Tsinghua University
C. Metz
Cisco Systems, Inc.
March 2010
4over6 Transit Solution Using IP Encapsulation and MP-BGP Extensions
Abstract
The emerging and growing deployment of IPv6 networks will introduce
cases where connectivity with IPv4 networks crossing IPv6 transit
backbones is desired. This document describes a mechanism for
automatic discovery and creation of IPv4-over-IPv6 tunnels via
extensions to multiprotocol BGP. It is targeted at connecting
islands of IPv4 networks across an IPv6-only backbone without the
need for a manually configured overlay of tunnels. The mechanisms
described in this document have been implemented, tested, and
deployed on the large research IPv6 network in China.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not 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/rfc5747">http://www.rfc-editor.org/info/rfc5747</a>.
IESG Note
The mechanisms and techniques described in this document are related
to specifications developed by the IETF softwire working group and
published as Standards Track documents by the IETF, but the
relationship does not prevent publication of this document.
<span class="grey">Wu, et al. Experimental [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
Copyright Notice
Copyright (c) 2010 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.
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. 4over6 Framework Overview .......................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Prototype Implementation ........................................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. 4over6 Packet Forwarding ...................................<a href="#page-5">5</a>
<a href="#section-3.2">3.2</a>. Encapsulation Table ........................................<a href="#page-6">6</a>
<a href="#section-3.3">3.3</a>. MP-BGP 4over6 Protocol Extensions ..........................<a href="#page-7">7</a>
<a href="#section-3.3.1">3.3.1</a>. Receiving Routing Information from Local CE .........<a href="#page-8">8</a>
3.3.2. Receiving 4over6 Routing Information from a
Remote 4over6 PE ....................................<a href="#page-8">8</a>
<a href="#section-4">4</a>. 4over6 Deployment Experience ....................................<a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. CNGI-CERNET2 ...............................................<a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network ............<a href="#page-9">9</a>
<a href="#section-4.3">4.3</a>. Deployment Experiences ....................................<a href="#page-10">10</a>
<a href="#section-5">5</a>. Ongoing Experiment .............................................<a href="#page-11">11</a>
<a href="#section-6">6</a>. Relationship to Softwire Mesh Effort ...........................<a href="#page-12">12</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-12">12</a>
<a href="#section-8">8</a>. Security Considerations ........................................<a href="#page-13">13</a>
<a href="#section-9">9</a>. Conclusion .....................................................<a href="#page-13">13</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-13">13</a>
<a href="#section-11">11</a>. Normative References ..........................................<a href="#page-14">14</a>
<span class="grey">Wu, et al. Experimental [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Due to the lack of IPv4 address space, more and more IPv6 networks
have been deployed not only on edge networks but also on backbone
networks. However, there are still a large number of legacy IPv4
hosts and applications. As a result, IPv6 networks and IPv4
applications/hosts will have to coexist for a long period of time.
The emerging and growing deployment of IPv6 networks will introduce
cases where connectivity with IPv4 networks is desired. Some IPv6
backbones will need to offer transit services to attached IPv4 access
networks. The method to achieve this would be to encapsulate and
then transport the IPv4 payloads inside IPv6 tunnels spanning the
backbone. There are some IPv6/IPv4-related tunneling protocols and
mechanisms defined in the literature. But at the time that the
mechanism described in this document was introduced, most of these
existing techniques focused on the problem of IPv6 over IPv4, rather
than the case of IPv4 over IPv6. Encapsulation methods alone, such
as those defined in [<a href="./rfc2473" title=""Generic Packet Tunneling in IPv6 Specification"">RFC2473</a>], require manual configuration in order
to operate. When a large number of tunnels are necessary, manual
configuration can become burdensome. To the above problem, this
document describes an approach, referred to as "4over6".
The 4over6 mechanism concerns two aspects: the control plane and the
data plane. The control plane needs to address the problem of how to
set up an IPv4-over-IPv6 tunnel in an automatic and scalable fashion
between a large number of edge routers. This document describes
experimental extensions to Multiprotocol Extension for BGP (MP-BGP)
[<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] [<a href="./rfc4760" title=""Multiprotocol Extensions for BGP-4"">RFC4760</a>] employed to communicate tunnel endpoint
information and establish 4over6 tunnels between dual-stack Provider
Edge (PE) routers positioned at the edge of the IPv6 backbone
network. Once the 4over6 tunnel is in place, the data plane focuses
on the packet forwarding processes of encapsulation and
decapsulation.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. 4over6 Framework Overview</span>
In the topology shown in Figure 1, a number of IPv6-only P routers
compose a native IPv6 backbone. The PE routers are dual stack and
referred to as 4over6 PE routers. The IPv6 backbone acts as a
transit core to transport IPv4 packets across the IPv6 backbone.
This enables each of the IPv4 access islands to communicate with one
another via 4over6 tunnels spanning the IPv6 transit core.
<span class="grey">Wu, et al. Experimental [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| |
| |
__+____________________+__
4over6 / : : : : \ IPv6 only
Tunnels | : : : : | transit core
between | : [P] : | with multiple
PEs | : : : : | [P routers]
| : : : : |
\_._._._._._._._._._._._._./
| / \ |
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| | |
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
Figure 1: IPv4 over IPv6 Network Topology
As shown in Figure 1, there are multiple dual-stack PE routers
connected to the IPv6 transit core. In order for the ingress 4over6
PE router to forward an IPv4 packet across the IPv6 backbone to the
correct egress 4over6 PE router, the ingress 4over6 PE router must
learn which IPv4 destination prefixes are reachable through each
egress 4over6 PE router. MP-BGP will be extended to distribute the
destination IPv4 prefix information between peering dual-stack PE
routers. <a href="#section-4">Section 4</a> of this document presents the definition of the
4over6 protocol field in MP-BGP, and <a href="#section-5">Section 5</a> describes MP-BGP's
extended behavior in support of this capability.
After the ingress 4over6 PE router learns the correct egress 4over6
PE router via MP-BGP, it will forward the packet across the IPv6
backbone using IP encapsulation. The egress 4over6 PE router will
receive the encapsulated packet, remove the IPv6 header, and then
forward the original IPv4 packet to its final IPv4 destination.
<a href="#section-6">Section 6</a> describes the procedure of packet forwarding.
<span class="grey">Wu, et al. Experimental [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Prototype Implementation</span>
An implementation of the 4over6 mechanisms described in this document
was developed, tested, and deployed on Linux with kernel version 2.4.
The prototype system is composed of three components: packet
forwarding, the encapsulation table, and MP-BGP extensions. The
packet forwarding and encapsulation table are Linux kernel modules,
and the MP-BGP extension was developed by extending Zebra routing
software.
The following sections will discuss these parts in detail.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. 4over6 Packet Forwarding</span>
Forwarding an IPv4 packet through the IPv6 transit core includes
three parts: encapsulation of the incoming IPv4 packet with the IPv6
tunnel header, transmission of the encapsulated packet over the IPv6
transit backbone, and decapsulation of the IPv6 header and forwarding
of the original IPv4 packet. Native IPv6 routing and forwarding are
employed in the backbone network since the P routers take the 4over6
tunneled packets as just native IPv6 packets. Therefore, 4over6
packet forwarding involves only the encapsulation process and the
decapsulation process, both of which are performed on the 4over6 PE
routers.
Tunnel from Ingress PE to Egress PE
---------------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+
|S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D|
+-+ +--+ +--+ +-+
Original Ingress PE Egress PE Original
Packet (Encapsulation) (Decapsulation) Packet
Source Destination
Node Node
Figure 2: Packet Forwarding along 4over6 Tunnel
As shown in Figure 2, packet encapsulation and decapsulation are both
on the dual-stack 4over6 PE routers. Figure 3 shows the format of
packet encapsulation and decapsulation.
<span class="grey">Wu, et al. Experimental [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
|
|(Encapsulation on ingress PE)
|
v
< Tunnel IPv6 Headers > < Original IPv4 Packet >
+-----------+ - - - - - +-------------+-----------//--------------+
| IPv6 | IPv6 | IPv4 | |
| | Extension | | Packet Payload |
| Header | Headers | Header | |
+-----------+ - - - - - +-------------+-----------//--------------+
< Tunnel IPv6 Packet >
|
|(Decapsulation on egress PE)
|
v
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
Figure 3: Packet Encapsulation and Decapsulation on Dual-Stack 4over6
PE Router
The encapsulation format to apply is IPv4 encapsulated in IPv6, as
outlined in [<a href="./rfc2473" title=""Generic Packet Tunneling in IPv6 Specification"">RFC2473</a>].
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Encapsulation Table</span>
Each 4over6 PE router maintains an encapsulation table as depicted in
Figure 4. Each entry in the encapsulation table consists of an IPv4
prefix and its corresponding IPv6 address. The IPv4 prefix is a
particular network located in an IPv4 access island network. The
IPv6 address is the 4over6 virtual interface (VIF) address of the
4over6 PE router that the IPv4 prefix is reachable through. The
encapsulation table is built and maintained using local configuration
information and MP-BGP advertisements received from remote 4over6 PE
routers.
The 4over6 VIF is an IPv6 /128 address that is locally configured on
each 4over6 router. This address, as an ordinary global IPv6
address, must also be injected into the IPv6 IGP so that it is
reachable across the IPv6 backbone.
<span class="grey">Wu, et al. Experimental [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
+-------------+------------------------------------------------+
| IPv4 Prefix | IPv6 Advertising Address Family Border Router |
+-------------+------------------------------------------------+
Figure 4: Encapsulation Table
When an IPv4 packet arrives at the ingress 4over6 PE router, a lookup
in the local IPv4 routing table will result in a pointer to the local
encapsulation table entry with the matching destination IPv4 prefix.
There is a corresponding IPv6 address in the encapsulation table.
The IPv4 packet is encapsulated in an IPv6 header. The source
address in the IPv6 header is the IPv6 VIF address of the local
4over6 PE router and the destination address is the IPv6 VIF address
of the remote 4over6 PE router contained in the local encapsulation
table. The packet is then subjected to normal IPv6 forwarding for
transport across the IPv6 backbone.
When the encapsulated packet arrives at the egress 4over6 PE router,
the IPv6 header is removed and the original IPv4 packet is forwarded
to the destination IPv4 network based on the outcome of the lookup in
the IPv4 routing table contained in the egress 4over6 PE router.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. MP-BGP 4over6 Protocol Extensions</span>
Each 4over6 PE router possesses an IPv4 interface connected to an
IPv4 access network(s). It can peer with other IPv4 routers using
IGP or BGP routing protocols to exchange local IPv4 routing
information. Routing information can also be installed on the 4over6
PE router using static configuration methods.
Each 4over6 PE also possesses at least one IPv6 interface to connect
it into the IPv6 transit backbone. The 4over6 PE typically uses IGP
routing protocols to exchange IPv6 backbone routing information with
other IPv6 P routers. The 4over6 PE router will also form an MP-iBGP
(Internal BGP) peering relationship with other 4over6 PE routers
connected to the IPv6 backbone network.
The use of MP-iBGP suggests that the participating 4over6 PE routers
that share a route reflector or form a full mesh of TCP connections
are contained in the same autonomous system (AS). This
implementation is in fact only deployed over a single AS. This was
not an intentional design constraint but rather reflected the single
AS topology of the CNGI-CERNET2 (China Next Generation Internet -
China Education and Research Network) national IPv6 backbone used in
the testing and deployment of this solution.
<span class="grey">Wu, et al. Experimental [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Receiving Routing Information from Local CE</span>
When a 4over6 PE router learns routing information from the locally
attached IPv4 access networks, the 4over6 MP-iBGP entity should
process the information as follows:
1. Install and maintain local IPv4 routing information in the IPv4
routing database.
2. Install and maintain new entries in the encapsulation table.
Each entry should consist of the IPv4 prefix and the local IPv6
VIF address.
3. Advertise the new contents of the local encapsulation table in
the form of MP_REACH_NLRI update information to remote 4over6 PE
routers. The format of these updates is as follows:
* AFI = 1 (IPv4)
* SAFI = 67 (4over6)
* NLRI = IPv4 network prefix
* Network Address of Next Hop = IPv6 address of its 4over6 VIF
4. A new Subsequent Address Family Identifier (SAFI) BGP 4over6 (67)
has been assigned by IANA. We call a BGP update with a SAFI of
67 as 4over6 routing information.
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Receiving 4over6 Routing Information from a Remote 4over6 PE</span>
A local 4over6 PE router will receive MP_REACH_NLRI updates from
remote 4over6 routers and use that information to populate the local
encapsulation table and the BGP routing database. After validating
the correctness of the received attribute, the following procedures
are used to update the local encapsulation table and redistribute new
information to the local IPv4 routing table:
1. Validate the received BGP update packet as 4over6 routing
information by AFI = 1 (IPv4) and SAFI = 67 (4over6).
2. Extract the IPv4 network address from the NLRI field and install
as the IPv4 network prefix.
3. Extract the IPv6 address from the Network Address of the Next Hop
field and place that as an associated entry next to the IPv4
network index. (Note, this describes the update of the local
encapsulation table.)
<span class="grey">Wu, et al. Experimental [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
4. Install and maintain a new entry in the encapsulation table with
the extracted IPv4 prefix and its corresponding IPv6 address.
5. Redistribute the new 4over6 routing information to the local IPv4
routing table. Set the destination network prefix as the
extracted IPv4 prefix, set the Next Hop as Null, and Set the
OUTPUT Interface as the 4over6 VIF on the local 4over6 PE router.
Therefore, when an ingress 4over6 PE router receives an IPv4 packet,
the lookup in its IPv4 routing table will have a result of the output
interface as the local 4over6 VIF, where the incoming IPv4 packet
will be encapsulated with a new IPv6 header, as indicated in the
encapsulation table.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. 4over6 Deployment Experience</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. CNGI-CERNET2</span>
A prototype of the 4over6 solution is implemented and deployed on
CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation
Internet (CNGI) backbones, operated by the China Education and
Research Network (CERNET). CNGI-CERNET2 connects approximately 25
core nodes distributed in 20 cities in China at speeds of 2.5-10
Gb/s. The CNGI-CERNET2 backbone is IPv6-only with some attached
customer premise networks (CPNs) being dual stack. The CNGI-CERNET2
backbone, attached CNGI-CERNET2 CPNs, and CNGI-6IX Exchange all have
globally unique AS numbers. This IPv6 backbone is used to provide
transit IPv4 services for customer IPv4 networks connected via 4over6
PE routers to the backbone.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network</span>
Figure 5 shows 4over6 deployment network topology.
<span class="grey">Wu, et al. Experimental [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
+-----------------------------------------------------+
| IPv6 (CERNET2) |
| |
+-----------------------------------------------------+
| | | |
Tsinghua|Univ. Peking|Univ. SJTU| Southeast|Univ.
+------+ +------+ +------+ +------+
|4over6| ... |4over6| |4over6| ... |4over6|
|router| |router| |router| |router|
+------+ +------+ +------+ +------+
| | | |
| | | |
| | | |
+-----------+ +-----------+ +-----------+ +-----------+
|IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access|
| network | | network | | network | | network |
+-----------+ +-----------+ +-----------+ +-----------+
|
+----------------------+
| IPv4 (Internet) |
| |
+----------------------+
Figure 5: 4over6 Deployment Network Topology
The IPv4-only access networks are equipped with servers and clients
running different applications. The 4over6 PE routers are deployed
at 8 x IPv6 nodes of CNGI-CERNET2, located in seven universities and
five cities across China. As suggested in Figure 5, some of the IPv4
access networks are connected to both IPv6 and IPv4 networks, and
others are only connected to the IPv6 backbone. In the deployment,
users in different IPv4 networks can communicate with each other
through 4over6 tunnels.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Deployment Experiences</span>
A number of 4over6 PE routers were deployed and configured to support
the 4over6 transit solution. MP-BGP peerings were established, and
successful distribution of 4over6 SAFI information occurred.
Inspection of the BGP routing and encapsulation tables confirmed that
the correct entries were sent and received. ICMP ping traffic
indicated that IPv4 packets were successfully transiting the IPv6
backbone.
In addition, other application protocols were successfully tested per
the following:
<span class="grey">Wu, et al. Experimental [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
o HTTP. A client running Internet Explorer in one IPv4 client
network was able to access and download multiple objects from an
HTTP server located in another IPv4 client network.
o P2P. BitComet software running on several PCs placed in different
IPv4 client networks were able to find each other and share files.
Other protocols, including FTP, SSH, IM (e.g., MSN, Google Talk), and
Multimedia Streaming, all functioned correctly.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Ongoing Experiment</span>
Based on the above successful experiment, we are going to have
further experiments in the following two aspects.
1. Inter-AS 4over6
The above experiment is only deployed over a single AS. With the
growth of the network, there could be multiple ASes between the
edge networks. Specifically, the Next Hop field in MP-BGP
indicates the tunnel endpoint in the current 4over6 technology.
However, in the Inter-AS scenario, the tunnel endpoint needs to be
separated from the field of Next Hop. Moreover, since the
technology of 4over6 is deployed on the router running MP-BGP, the
supportability of 4over6 on each Autonomous System Border Router
(ASBR) will be a main concern in the Inter-AS experiment. We may
consider different situations: (1) Some ASBRs do not support
4over6; (2) ASBRs only support the 4over6 control plane (i.e., MP-
BGP extension of 4over6) rather than 4over6 data plane; (3) ASBRs
support both the control plane and the data plane for 4over6.
2. Multicast 4over6
The current 4over6 technology only supports unicast routing and
data forwarding. With the deployment of network-layer multicast
in multiple IPv4 edge networks, we need to extend the 4over6
technology to support multicast including both multicast tree
manipulation on the control plane and multicast traffic forwarding
on the data plane. Based on the current unicast 4over6 technology
providing the unicast connectivity of edge networks over the
backbone in another address family, the multicast 4over6 will
focus on the mapping technologies between the multicast groups in
the different address families.
<span class="grey">Wu, et al. Experimental [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Relationship to Softwire Mesh Effort</span>
The 4over6 solution was presented at the IETF Softwires Working Group
Interim meeting in Hong Kong in January 2006. The existence of this
large-scale implementation and deployment clearly showed that MP-BGP
could be employed to support tunnel setup in a scalable fashion
across an IPv6 backbone. Perhaps most important was the use-case
presented -- an IPv6 backbone that offers transit to attached client
IPv4 networks.
The 4over6 solution can be viewed as a precursor to the Softwire Mesh
Framework proposed in the softwire problem statement [<a href="./rfc4925" title=""Softwire Problem Statement"">RFC4925</a>].
However, there are several differences with this solution and the
effort that emerged from the Softwires Working Group called "softwire
Mesh Framework" [<a href="./rfc5565" title=""Softwire Mesh Framework"">RFC5565</a>] and the related solutions [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>]
[<a href="./rfc5549" title=""Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop"">RFC5549</a>].
o MP-BGP Extensions. 4over6 employs a new SAFI (BGP 4over6) to
convey client IPv4 prefixes between 4over6 PE routers. Softwire
Mesh retains the original AFI-SAFI designations, but it uses a
modified MP_REACH_NLRI format to convey IPv4 Network Layer
Reachability Information (NLRI) prefix information with an IPv6
next_hop address [<a href="./rfc5549" title=""Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop"">RFC5549</a>].
o Encapsulation. 4over6 assumes IP-in-IP or it is possible to
configure Generic Routing Encapsulation (GRE). Softwires uses
those two scenarios configured locally or for IP headers that
require dynamic updating. As a result, the BGP encapsulation SAFI
is introduced in [<a href="./rfc5512" title=""The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute"">RFC5512</a>].
o Multicast. The basic 4over6 solution only implemented unicast
communications. The multicast communications are specified in the
Softwire Mesh Framework and are also supported by the multicast
extension of 4over6.
o Use-Cases. The 4over6 solution in this document specifies the
4over6 use-case, which is also pretty easy to extend for the use-
case of 6over4. The Softwire Mesh Framework supports both 4over6
and 6over4.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
A new SAFI value (67) has been assigned by IANA for the BGP 4over6
SAFI.
<span class="grey">Wu, et al. Experimental [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Tunneling mechanisms, especially automatic ones, often have potential
problems of Distributed Denial of Service (DDoS) attacks on the
tunnel entry-point or tunnel exit-point. As the advantage, the BGP
4over6 extension doesn't allocate resources to a single flow or
maintain the state for a flow. However, since the IPv6 tunnel
endpoints are globally reachable IPv6 addresses, it would be trivial
to spoof IPv4 packets by encapsulating and sending them over IPv6 to
the tunnel interface. This could bypass IPv4 Reverse Path Forwarding
(RPF) or other antispoofing techniques. Also, any IPv4 filters may
be bypassed.
An iBGP peering relationship may be maintained over IPsec or other
secure communications.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Conclusion</span>
The emerging and growing deployment of IPv6 networks, in particular,
IPv6 backbone networks, will introduce cases where connectivity with
IPv4 networks is desired. Some IPv6 backbones will need to offer
transit services to attached IPv4 access networks. The 4over6
solution outlined in this document supports such a capability through
an extension to MP-BGP to convey IPv4 routing information along with
an associated IPv6 address. Basic IP encapsulation is used in the
data plane as IPv4 packets are tunneled through the IPv6 backbone.
An actual implementation has been developed and deployed on the CNGI-
CERNET2 IPv6 backbone.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
During the design procedure of the 4over6 framework and definition of
BGP-MP 4over6 extension, Professor Ke Xu gave the authors many
valuable comments. The support of the IETF Softwires WG is also
gratefully acknowledged with special thanks to David Ward, Alain
Durand, and Mark Townsley for their rich experience and knowledge in
this field. Yakov Rekhter provided helpful comments and advice.
Mark Townsley reviewed this document carefully and gave the authors a
lot of valuable comments, which were very important for improving
this document.
The deployment and test for the prototype system was conducted among
seven universities -- namely, Tsinghua University, Peking University,
Beijing University of Post and Telecommunications, Shanghai Jiaotong
University, Huazhong University of Science and Technology, Southeast
<span class="grey">Wu, et al. Experimental [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
University, and South China University of Technology. The authors
would like to thank everyone involved in this effort at these
universities.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Normative References</span>
[<a id="ref-RFC2473">RFC2473</a>] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", <a href="./rfc2473">RFC 2473</a>, December 1998.
[<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January 2006.
[<a id="ref-RFC4760">RFC4760</a>] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", <a href="./rfc4760">RFC 4760</a>,
January 2007.
[<a id="ref-RFC4925">RFC4925</a>] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire
Problem Statement", <a href="./rfc4925">RFC 4925</a>, July 2007.
[<a id="ref-RFC5512">RFC5512</a>] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", <a href="./rfc5512">RFC 5512</a>, April 2009.
[<a id="ref-RFC5549">RFC5549</a>] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
<a href="./rfc5549">RFC 5549</a>, May 2009.
[<a id="ref-RFC5565">RFC5565</a>] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", <a href="./rfc5565">RFC 5565</a>, June 2009.
<span class="grey">Wu, et al. Experimental [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5747">RFC 5747</a> 4over6 March 2010</span>
Authors' Addresses
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5822
EMail: cy@csnet1.cs.tsinghua.edu.cn
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5983
EMail: xing@cernet.edu.cn
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R. China
Phone: +86-10-6278-5822
EMail: xmw@csnet1.cs.tsinghua.edu.cn
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, CA 95134
USA
EMail: chmetz@cisco.com
Wu, et al. Experimental [Page 15]
</pre>
|
