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
|
<pre>Internet Engineering Task Force (IETF) V. Kuarsingh, Ed.
Request for Comments: 7289 J. Cianfarani
Category: Informational Rogers Communications
ISSN: 2070-1721 June 2014
<span class="h1">Carrier-Grade NAT (CGN) Deployment with BGP/MPLS IP VPNs</span>
Abstract
This document specifies a framework to integrate a Network Address
Translation (NAT) layer into an operator's network to function as a
Carrier-Grade NAT (also known as CGN or Large-Scale NAT). The CGN
infrastructure will often form a NAT444 environment as the subscriber
home network will likely also maintain a subscriber-side NAT
function. Exhaustion of the IPv4 address pool is a major driver
compelling some operators to implement CGN. Although operators may
wish to deploy IPv6 to strategically overcome IPv4 exhaustion, near-
term needs may not be satisfied with an IPv6 deployment alone. This
document provides a practical integration model that allows the CGN
platform to be integrated into the network, meeting the connectivity
needs of the subscriber while being mindful of not disrupting
existing services and meeting the technical challenges that CGN
brings. The model included in this document utilizes BGP/MPLS IP
VPNs, which allow for virtual routing separation, helping ease the
CGN's impact on the network. This document does not intend to defend
the merits of CGN.
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/rfc7289">http://www.rfc-editor.org/info/rfc7289</a>.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Copyright Notice
Copyright (c) 2014 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.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
<a href="#section-1.1">1.1</a>. Acronyms and Terms .........................................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Existing Network Considerations .................................<a href="#page-5">5</a>
<a href="#section-3">3</a>. CGN Network Deployment Requirements .............................<a href="#page-5">5</a>
<a href="#section-3.1">3.1</a>. Centralized versus Distributed Deployment ..................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. CGN and Traditional IPv4 Service Coexistence ...............<a href="#page-7">7</a>
<a href="#section-3.3">3.3</a>. CGN Bypass .................................................<a href="#page-7">7</a>
<a href="#section-3.4">3.4</a>. Routing Plane Separation ...................................<a href="#page-8">8</a>
<a href="#section-3.5">3.5</a>. Flexible Deployment Options ................................<a href="#page-8">8</a>
<a href="#section-3.6">3.6</a>. IPv4 Overlap Space .........................................<a href="#page-9">9</a>
<a href="#section-3.7">3.7</a>. Transactional Logging for CGN Systems ......................<a href="#page-9">9</a>
<a href="#section-3.8">3.8</a>. Base CGN Requirements ......................................<a href="#page-9">9</a>
<a href="#section-4">4</a>. BGP/MPLS IP VPN-Based CGN Framework .............................<a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Service Separation ........................................<a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Internal Service Delivery .................................<a href="#page-12">12</a>
<a href="#section-4.2.1">4.2.1</a>. Dual-Stack Operation ...............................<a href="#page-14">14</a>
<a href="#section-4.3">4.3</a>. Deployment Flexibility ....................................<a href="#page-16">16</a>
4.4. Comparison of BGP/MPLS IP VPN Option versus Other
CGN Attachment Options ....................................<a href="#page-16">16</a>
<a href="#section-4.4.1">4.4.1</a>. Policy-Based Routing ...............................<a href="#page-16">16</a>
<a href="#section-4.4.2">4.4.2</a>. Traffic Engineering ................................<a href="#page-17">17</a>
<a href="#section-4.4.3">4.4.3</a>. Multiple Routing Topologies ........................<a href="#page-17">17</a>
<a href="#section-4.5">4.5</a>. Multicast Considerations ..................................<a href="#page-17">17</a>
<a href="#section-5">5</a>. Experiences ....................................................<a href="#page-17">17</a>
<a href="#section-5.1">5.1</a>. Basic Integration and Requirements Support ................<a href="#page-17">17</a>
<a href="#section-5.2">5.2</a>. Performance ...............................................<a href="#page-18">18</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-18">18</a>
<a href="#section-7">7</a>. BGP/MPLS IP VPN CGN Framework Discussion .......................<a href="#page-18">18</a>
<a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-19">19</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-19">19</a>
<a href="#section-9.1">9.1</a>. Normative Reference .......................................<a href="#page-19">19</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-19">19</a>
<span class="grey">Kuarsingh & Cianfarani Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Operators are faced with near-term IPv4 address-exhaustion
challenges. Many operators may not have a sufficient amount of IPv4
addresses in the future to satisfy the needs of their growing
subscriber base. This challenge may also be present before or during
an active transition to IPv6, somewhat complicating the overall
problem space.
To face this challenge, operators may need to deploy CGN (Carrier-
Grade NAT) as described in [<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>] to help extend the connectivity
matrix once IPv4 address caches run out on the local operator. CGN
deployments will most often be added into operator networks that
already have active IPv4 and/or IPv6 services.
The addition of the CGN introduces a translation layer that is
controlled and administered by an operator and that should be added
in a manner that minimizes disruption to existing services. The CGN
system addition may also include interworking in a dual-stack
environment where the IPv4 path requires translation.
This document shows how BGP/MPLS IP VPNs as described in [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>]
can be used to integrate the CGN infrastructure solving key
integration challenges faced by the operator. This model has also
been tested and validated in real production-network models and
allows fluid operation with existing IPv4 and IPv6 services.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Acronyms and Terms</span>
Acronyms and terms used in this document are defined in the list
below.
CGN - Carrier-Grade NAT
DOCSIS - Data Over Cable Service Interface Specification
CMTS - Cable Modem Termination System
DSL - Digital Subscriber Line
BRAS - Broadband Remote Access Server
GGSN - Gateway GPRS Support Node
GPRS - General Packet Radio Service
ASN-GW - Access Service Network Gateway
<span class="grey">Kuarsingh & Cianfarani Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
GRT - Global Routing Table
Internal Realm - Addressing and/or network zone between the
Customer Premises Equipment (CPE) and CGN as specified in
[<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>]
External Realm - Public-side network zone and addressing on the
Internet-facing side of the CGN as specified in [<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>]
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Existing Network Considerations</span>
The selection of CGN may be made by an operator based on a number of
factors. The overall driver to use CGN may be the depletion of IPv4
address pools, which leaves little to no addresses for a growing IPv4
service or connection demand growth. IPv6 is considered the
strategic answer for IPv4 address depletion; however, the operator
may independently decide that CGN is needed to supplement IPv6 and
address their particular IPv4 service deployment needs.
If the operator has chosen to deploy CGN, they should do this in a
manner as not to negatively impact the existing IPv4 or IPv6
subscriber base. This will include solving a number of challenges
since subscribers whose connections require translation will have
network routing and flow needs that are different from legacy IPv4
connections.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. CGN Network Deployment Requirements</span>
If a service provider is considering a CGN deployment with a provider
NAT44 function, there are a number of basic architectural
requirements that are of importance. Preliminary architectural
requirements may require all or some of those captured in the list
below. Each of the architectural requirement items listed is
expanded upon in the following subsections. It should be noted that
architectural CGN requirements are additive to base CGN functional
requirements contained in [<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>]. The assessed architectural
requirements for deployment are:
- Support distributed (sparse) and centralized (dense) deployment
models. See <a href="#section-3.1">Section 3.1</a>
- Allow coexistence with traditional IPv4-based deployments, which
provide global-scoped IPv4 addresses to CPEs. See <a href="#section-3.2">Section 3.2</a>.
- Provide a framework for CGN bypass supporting non-translated flows
between endpoints within a provider's network. See <a href="#section-3.3">Section 3.3</a>.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
- Provide a routing framework that allows the segmentation of
routing control and forwarding paths between CGN-mediated and non-
CGN-mediated flows. See <a href="#section-3.4">Section 3.4</a>.
- Provide flexibility for operators to modify their deployments over
time as translation demands change (connections, bandwidth,
translation realms/zones, and other vectors). See <a href="#section-3.5">Section 3.5</a>.
- Flexibility should include integration options for common access
technologies such as DSL (BRAS), DOCSIS (CMTS), Mobile (GGSN/PGW/
ASN-GW), and direct Ethernet. See <a href="#section-3.5">Section 3.5</a>.
- Support deployment modes that allow for IPv4 address overlap
within the operator's network (between various translation realms
or zones). See <a href="#section-3.6">Section 3.6</a>.
- Allow for evolution to future dual-stack and IPv4/IPv6 transition
deployment modes. See <a href="#section-3.5">Section 3.5</a>.
- Transactional logging and export capabilities to support auxiliary
functions, including abuse mitigation. See <a href="#section-3.7">Section 3.7</a>.
- Support for stateful connection synchronization between
translation instances/elements (redundancy). See <a href="#section-3.8">Section 3.8</a>.
- Support for CGN Shared Address Space [<a href="./rfc6598" title=""IANA-Reserved IPv4 Prefix for Shared Address Space"">RFC6598</a>] deployment modes if
applicable. See <a href="#section-3.6">Section 3.6</a>.
- Allow for the enablement of CGN functionality (if required) while
still minimizing costs and subscriber impact to the best extend
possible. See <a href="#section-3.8">Section 3.8</a>.
Other requirements may be assessed on an operator-by-operator basis,
but those listed above may be considered for any given deployment
architecture.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Centralized versus Distributed Deployment</span>
Centralized deployments of CGN (longer proximity to end user and/or
higher densities of subscribers/connections to CGN instances) differ
from distributed deployments of CGN (closer proximity to end user
and/or lower densities of subscribers/connections to CGN instances).
Service providers may likely deploy CGN translation points more
centrally during initial phases if the early system demand is low.
Early deployments may see light loading on these new systems since
legacy IPv4 services will continue to operate with most endpoints
using globally unique IPv4 addresses. Exceptional cases that may
drive heavy usage in initial stages may include operators that
<span class="grey">Kuarsingh & Cianfarani Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
already translate a significant portion of their IPv4 traffic,
operators that may transition to a CGN implementation from legacy
translation mechanisms (i.e., traditional firewalls), or operators
that build a greenfield deployment that may see quick growth in the
number of new IPv4 endpoints that require Internet connectivity.
Over time, some providers may need to expand and possibly distribute
the translation points if demand for the CGN system increases. The
extent of the expansion of the CGN infrastructure will depend on
factors such as growth in the number of IPv4 endpoints, status of
IPv6 content on the Internet, and the overall progress globally to an
IPv6-dominate Internet (reducing the demand for IPv4 connectivity).
The overall demand for CGN resources will probably follow a bell-like
curve with a growth, peak, and decline period.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. CGN and Traditional IPv4 Service Coexistence</span>
Newer CGN-serviced endpoints will exist alongside endpoints served by
traditional IPv4 globally routed addresses. Operators will need to
rationalize these environments since both have distinct forwarding
needs. Traditional IPv4 services will likely require (or be best
served by) direct forwarding toward Internet peering points while
CGN-mediated flows require access to a translator. CGN-mediated and
non-CGN-mediated flows pose two fundamentally different forwarding
needs.
The new CGN environments should not negatively impact the existing
IPv4 service base by forcing all traffic to translation-enabled
network points since many flows do not require translation and this
would reduce performance of the existing flows. This would also
require massive scaling of the CGN, which is a cost and efficiency
concern as well.
Efficiency of traffic flow and forwarding is considered important
since networks are under considerable demand to deliver more and more
bandwidth without the luxury of needless inefficiencies that can be
introduced with CGN.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. CGN Bypass</span>
The CGN environment is only needed for flows with translation
requirements. Many flows that remain within the operator's network
do not require translation. Such services include operator-offered
DNS services, DHCP services, NTP services, web caching, email, news,
and other services that are local to the operator's network.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
The operator may want to leverage opportunities to offer third
parties a platform to also provide services without translation. CGN
bypass can be accomplished in many ways, but a simplistic,
deterministic, and scalable model is preferred.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Routing Plane Separation</span>
Many operators will want to engineer traffic separately for CGN flows
versus flows that are part of the more traditional IPv4 environment.
Many times, the routing of these two major flow types differ;
therefore, route separation may be required.
Routing-plane separation also allows the operator to utilize other
addressing techniques, which may not be feasible on a single routing
plane. Such examples include the use of overlapping private address
space [<a href="./rfc1918" title=""Address Allocation for Private Internets"">RFC1918</a>], Shared Address Space [<a href="./rfc6598" title=""IANA-Reserved IPv4 Prefix for Shared Address Space"">RFC6598</a>], or other IPv4 space
that may overlap globally within the operator's network.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Flexible Deployment Options</span>
Service providers operate complex routing environments and offer a
variety of IPv4-based services. Many operator environments utilize
distributed external routing infrastructures for transit and peering,
and these may span large geographical areas. A CGN solution should
offer operators the ability to place CGN translation points at
various points within their network.
The CGN deployment should also be flexible enough to change over time
as demand for translation services increase or change as noted in
[<a href="./rfc6264" title=""An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition"">RFC6264</a>]. In turn, the deployment will need to then adapt as
translation demand decreases due to the transition of flows to IPv6.
Translation points should be able to be placed and moved with as
little re-engineering effort as possible, minimizing the risks to the
subscriber base.
Depending on hardware capabilities, security practices, and IPv4
address availability, the translation environments may need to be
segmented and/or scaled over time to meet organic IPv4 demand growth.
Operators may also want to choose models that support transition to
other translation environments such as Dual-Stack Lite (DS-Lite)
[<a href="./rfc6333" title=""Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion"">RFC6333</a>] and/or Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers (NAT64) [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>]. Operators will want to
seek deployment models that are conducive to meeting these goals as
well.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. IPv4 Overlap Space</span>
IPv4 address overlap for CGN translation realms may be required if
insufficient IPv4 addresses are available within the operator
environment to assign internally unique IPv4 addresses to the CGN
subscriber base. The CGN deployment should provide mechanisms to
manage IPv4 overlap if required.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. Transactional Logging for CGN Systems</span>
CGNs may require transactional logging since the source IP and
related transport-protocol information are not easily visible to
external hosts and system.
If needed, CGN systems should be able to generate logs that identify
internal-realm host parameters (i.e., IP/Port) and associate them to
external-realm parameters imposed by the translator. The logged
information should be stored on the CGN hardware and/or exported to
another system for processing. The operator may choose to also
enable mechanisms to help reduce logging, such as block allocation of
UDP and TCP ports or deterministic translation options, e.g.,
[<a href="#ref-CGN-DEPLOYMENTS">CGN-DEPLOYMENTS</a>].
Operators may be legally obligated to keep track of translation
information. The operator may need to utilize their standard
practices in handling sensitive customer data when storing and/or
transporting such data. Further information regarding CGN logging
requirements can be found in <a href="./rfc6888#section-4">Section 4 of [RFC6888]</a>.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. Base CGN Requirements</span>
Whereas the requirements above represent assessed architectural
requirements, the CGN platform will also need to meet the base CGN
requirements of a CGN function. Base requirements include functions
such as Bulk Port Allocation and other CGN device-specific functions.
These base CGN platform requirements are captured in [<a href="./rfc6888" title=""Common Requirements for Carrier-Grade NATs (CGNs)"">RFC6888</a>].
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. BGP/MPLS IP VPN-Based CGN Framework</span>
The BGP/MPLS IP VPN [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>] framework for CGN segregates the
internal realms within the service-provider space into Layer 3 MPLS-
based VPNs. The operator can deploy a single realm for all CGN-based
flows or can deploy multiple realms based on translation demand and
other factors such as geographical proximity. A realm in this model
refers to a "VPN", which shares a unique Route Distinguisher / Route
Target (RD/RT) combination, routing plane, and forwarding behaviors.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
The BGP/MPLS IP VPN infrastructure provides control-plane and
forwarding separation for the traditional IPv4 service environment
and CGN environment(s). The separation allows for routing
information (such as default routes) to be propagated separately for
CGN-based and non-CGN-based subscriber flows. Traffic can be
efficiently routed to the Internet for normal flows and routed
directly to translators for CGN-mediated flows. Although many
operators may run a "default-route-free" core, IPv4 flows that
require translation must obviously be routed first to a translator,
so a default route is acceptable for the internal realms.
The physical location of the Virtual Routing and Forwarding (VRF)
termination point for a BGP/MPLS IP VPN-enabled CGN can vary and be
located anywhere within the operator's network. This model fully
virtualizes the translation service from the base IPv4 forwarding
environment that will likely be carrying Internet-bound traffic. The
base IPv4 environment can continue to service traditional IPv4
subscriber flows plus post translated CGN flows.
Figure 1 provides a view of the basic model. The access node
provides CPE access to either the CGN VRF or the Global Routing
Table (GRT), depending on whether the subscriber receives a private
or public IP. Translator-mediated traffic follows an MPLS Label
Switched Path (LSP) that can be set up dynamically and can span one
hop or many hops (with no need for complex routing policies).
Traffic is then forwarded to the translator, which can be an external
appliance or integrated into the VRF Termination (Provider Edge)
router. Once traffic is translated, it is forwarded to the GRT for
general Internet forwarding. The GRT can also be a separate VRF
(Internet access VPN/VRF) should the provider choose to implement
their Internet-based services in that fashion. The translation
services are effectively overlaid onto the network but are maintained
within a separate forwarding and control plane.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Access Node VRF Termination CGN
+-----------+ +-----------+ +-----------+
| | | | | |
CPE | +-------+ | | +-------+ | | +-------+ |
+----+ | | | | LSP | | | | IP | | | |
| --+---+-+->VRF--+-+-----+-+->VRF--+-+----+-+-> | |
+----+ | | | | | | | | | | | |
| +-------+ | | +-------+ | | | | |
| | | | | | XLATE | |
| | | | | | | |
CPE-CGN | +-------+ | | +-------+ | | | | |
+----+ | | | | | | | | IP | | | |
| --+---+-+->GRT | | | | GRT<-+-+----+-+-- | |
+----+ | | | | | | | | | | | | | |
| +---+---+ | | +---+---+ | | +-------+ |
+-----+-----+ +-----+-----+ +-----------+
| |
| | IPv4
| | IP +---------+
| +------------+-> |
| IP | GRT |
+------------------------------+-> |
+---------+
Figure 1: Basic BGP/MPLS IP VPN CGN Model
If more then one VRF (translation realm) is used within the
operator's network, each VPN instance can manage CGN flows
independently for the respective realm. The described architecture
does not prescribe a single redundancy model that ensures network
availability as a result of CGN failure. Deployments are able to
select a redundancy model that fits best with their network design.
If state information needs to be passed or maintained between
hardware instances, the vendor would need to enable this feature in a
suitable manner.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Service Separation</span>
The MPLS/VPN CGN framework supports route separation. The
traditional IPv4 flows can be separated at the access node (initial
Layer 3 service point) from those that require translation. This
type of service separation is possible on common technologies used
for Internet access within many operator networks. Service
separation can be accomplished on common access technology, including
those used for DOCSIS (CMTS), Ethernet access, DSL (BRAS), and mobile
access (GGSN/ASN-GW) architectures.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Internal Service Delivery</span>
Internal services can be delivered directly to the privately
addressed endpoint within the CGN domain without translation. This
can be accomplished in one of two methods. The first method is the
use of "route leaking", a method of exchanging routes between the CGN
VRF and GRT; this method may also include reducing the overall number
of VRFs in the system and exposing services in the GRT. The second
method, which is described in detail within this section, is the use
of a Services VRF. The second model is a more traditional extranet
services model but requires more system resources to implement.
Using direct route exchange (import/export) between the CGN VRFs and
the Services VRFs creates reachability using the aforementioned
extranet model available in the BGP/MPLS IP VPN structure. This
model allows the provider to maintain separate forwarding rules for
translated flows, which require a pass through the translator to
reach external network entities, versus those flows that need to
access internal services. This operational detail can be
advantageous for a number of reasons, such as service-access policies
and endpoint identification. First, the provider can reduce the load
on the translator since internal services do not need to be factored
into the scaling of the CGN hardware (which may be quite large).
Second, more direct forwarding paths can be maintained to provide
better network efficiency. Third, geographic locations of the
translators and the services infrastructure can be deployed in
locations in an independent manner. Additionally, the operator can
allow CGN subject endpoints to be accessible via an untranslated
path, reducing the complexities of provider-initiated management
flows. This last point is of key interest since NAT removes
transparency to the end device in normal cases.
Figure 2 below shows how internal services are provided untranslated
since flows are sent directly from the access node to the services
node/VRF via an MPLS LSP. This traffic is not forwarded to the CGN
translator and therefore is not subject to problematic behaviors
related to NAT. The Services VRF contains routing information that
can be "imported" into the access node VRF, and the CGN VRF routing
information can be "imported" into the Services VRF.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Access Node VRF Termination CGN
+-------------+ +-----------+ +----------+
| | | | | |
CPE | +---------+ | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | |
| --+--+-+-> VRF --+-+--+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | | | |
| | | | | | |XLATE | |
| | | | | | | | |
CPE-CGN | +---------+ | | | +-------+ | | | | |
+-----+ | | | | | | | | | | | | |
| --+--+-+-> GRT | | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | | | |
| +----+----+ | | | +-------+ | | +------+ |
+------+------+ | +-----------+ +----------+
| |
| | IPv4
| | +-----------+
| +---------------+->Services |
| | VRF |
.-------------------------+-> | |
+-----+-----+
|
+-----V-----+
| |
| Local |
| Content |
+-----------+
Figure 2: Internal Services and CGN Bypass
An extension to the services delivery LSP is the ability to also
provide direct subscriber-to-subscriber traffic flows between CGN
zones. Each zone or realm may be fitted with separate CGN resources,
but the subtending subscribers don't necessarily need to be mediated
(translated) by the CGN translators. This option, as shown in
Figure 3, is easy to implement and can only be enabled if no IPv4
address overlap is used between communicating CGN zones.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Access Node-1 VRF Termination CGN-1
+-------------+ +-----------+ +----------+
| | | | | |
CPE-1 | +---------+ | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | |
| --+--+-+- VRF --+-+-+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | | | |
| | | | | | |XLATE | |
| | | | | | | | |
CPE-2-CGN| +---------+ | | | +-------+ | | | | |
+-----+ | | | | | | | | | | | | |
| --+--+-+- GRT | | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | | |
| +---------+ | | | +-------+ | | +------+ |
+-------------+ | +-----------+ +----------+
|
LSP |
|
Access Node-2 | VRF Termination CGN-2
+-------------+ | +-----------+ +----------+
| | | | | | |
CPE-3-CGN| +---------+ | | | +-------+ | | +------+ |
+-----+ | | | | | | | | | | | | |
| --+--+-+-- VRF --+-+-+ | | VRF | | | | | |
+-----+ | | | | | | | | | | | |
| +---------+ | | +-------+ | | | | |
| | | | | |XLATE | |
| | | | | | | |
CPE-4 | +---------+ | | +-------+ | | | | |
+-----+ | | | | | | | | | | | |
| --+--+-+- GRT | | | | GRT | | | | | |
+-----+ | | | | | | | | | | | |
| +---------+ | | +-------+ | | +------+ |
+-------------+ +-----------+ +----------+
Figure 3: Subscriber-to-Subscriber CGN Bypass
The inherent capabilities of the BGP/MPLS IP VPN model demonstrates
the ability to offer CGN bypass in a standard and deterministic
manner without the need of policy-based routing or traffic
engineering.
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Dual-Stack Operation</span>
The BGP/MPLS IP VPN CGN model can also be used in conjunction with
IPv4/IPv6 dual-stack service modes. Since many providers will use
CGNs on an interim basis while IPv6 matures within the global
<span class="grey">Kuarsingh & Cianfarani Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
Internet or due to technical constraints, a dual-stack option is of
strategic importance. Operators can offer this dual-stack service
for both traditional IPv4 (global IP) endpoints and CGN-mediated
endpoints.
Operators can separate the IP flows for IPv4 and IPv6 traffic, or
they can use other routing techniques to move IPv6-based flows toward
the GRT (Global Routing Table) while allowing IPv4 flows to remain
within the IPv4 CGN VRF for translator services.
Figure 4 shows how IPv4 translation services can be provided
alongside IPv6-based services. This model allows the provider to
enable CGN to manage IPv4 flows (translated), and IPv6 flows are
routed without translation efficiently toward the Internet. Once
again, forwarding of flows to the translator does not impact IPv6
flows, which do not require this service.
Access Node VRF Termination CGN
+-----------+ +-----------+ +-----------+
| | | | | |
CPE-CG | +-------+ | | +-------+ | | +-------+ |
+-----+ | | | |LSP| | | | IP | | | |
| --+--+-+->VRF--+-+---+-+->VRF--+-+----+-+> | |
|IPv4 | | | | | | | | | | | | |
| | | +-------+ | | +-------+ | | | | |
+-----| | | | | | | XLATE | |
|IPv6 | | | | | | | | |
| | | +-------+ | | +-------+ | | | | |
| | | | IPv6 | | | | IPv4 | | IP | | | |
| --+--+-+->GRT | | | | GRT<-+-+----+-+-- | |
+-----+ | | | | | | | | | | | | | |
| +---+---+ | | +---+---+ | | +-------+ |
+-----+-----+ +-----+-----+ +-----------+
| |
| | +-----------+
| | IP | IPv4 |
| +----------+-> GRT |
| +-----------+
|
|
|
| IP +-----------+
+--------------------------+-> IPv6 |
| GRT |
+-----------+
Figure 4: CGN with IPv6 Dual-Stack Operation
<span class="grey">Kuarsingh & Cianfarani Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Deployment Flexibility</span>
The CGN translator services can be moved, separated or segmented (new
translation realms) without the need to change the overall
translation design. Since dynamic LSPs are used to forward traffic
from the access nodes to the translation points, the physical
location of the VRF termination points can vary and be changed
easily.
This type of flexibility allows the service provider to initially
deploy more centralized translation services based on relatively low
loading factors and distribute the translation points over time to
improve network-traffic efficiencies and support higher translation
load.
Although traffic-engineered paths are not required within the MPLS/
VPN deployment model, nothing precludes an operator from using
technologies like MPLS with Traffic Engineering [<a href="./rfc3031" title=""Multiprotocol Label Switching Architecture"">RFC3031</a>].
Additional routing mechanisms can be used as desired by the provider
and can be seen as independent. There is no specific need to
diversify the existing infrastructure in most cases.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Comparison of BGP/MPLS IP VPN Option versus Other CGN Attachment</span>
<span class="h3"> Options</span>
Other integration architecture options exist that can attach CGN
based service flows to a translator instance. Alternate options that
can be used to attach such services include:
- policy-based routing (static) to direct translation-bound traffic
to a network-based translator;
- traffic engineering; and
- multiple routing topologies.
<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>. Policy-Based Routing</span>
Policy-based routing (PBR) provides another option to direct CGN-
mediated flows to a translator. PBR options, although possible, are
difficult to maintain (due to static policy) and must be configured
throughout the network with considerable maintenance overhead.
More centralized deployments may be difficult or too onerous to
deploy using policy-based routing methods. Policy-based routing
would not achieve route separation (unless used with others options)
and may add complexities to the providers' routing environment.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>. Traffic Engineering</span>
Traffic engineering can also be used to direct traffic from an access
node toward a translator. Traffic engineering, like MPLS-TE, may be
difficult to set up and maintain. Traffic engineering provides
additional benefits if used with MPLS by adding potential for faster
path re-convergence. Traffic engineering paths would need to be
updated and redefined over time as CGN translation points are
augmented or moved.
<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>. Multiple Routing Topologies</span>
Multiple routing topologies can be used to direct CGN-based flows to
translators. This option would achieve the same basic goal as the
MPLS/VPN option but with additional implementation overhead and
platform configuration complexity. Since operator based translation
is expected to have an unknown lifecycle, and may see various degrees
of demand (dependent on operator IPv4 Global space availability and
shift of traffic to IPv6), it may be too large of an undertaking for
the provider to enabled this as their primary option for CGN.
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. Multicast Considerations</span>
When deploying BGP/MPLS IP VPNs as a service method for user-plane
traffic to access CGN, one needs to be cognizant of current or future
IP multicast requirements. User-plane IP Multicast that may
originate outside of the VRF requires specific consideration. Adding
the requirement for user plane IP multicast can potentially cause
additional complexity related to importing and exporting the IP
multicast routes in addition to suboptimal scaling and bandwidth
utilization.
It is recommended to reference best practice and designs from
[<a href="./rfc6037" title=""Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs"">RFC6037</a>], [<a href="./rfc6513" title=""Multicast in MPLS/BGP IP VPNs"">RFC6513</a>], and [<a href="./rfc5332" title=""MPLS Multicast Encapsulations"">RFC5332</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Experiences</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Basic Integration and Requirements Support</span>
The MPLS/VPN CGN environment has been successfully integrated into
real network environments utilizing existing network service delivery
mechanisms. It solves many issues related to provider-based
translation environments while still subject to problematic behaviors
inherent within NAT.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
The key issues that are solved or managed with the MPLS/VPN option
include:
- Support for the centralized and distributed deployment model
- Routing plane separation for CGN flows versus traditional IPv4
flows
- Flexible translation point design (can relocate translators and
split translation zones easily)
- Low maintenance overhead (dynamic routing environment with little
maintenance of separate routing infrastructure other than
management of MPLS/VPNs)
- CGN bypass options (for internal and third-party services that
exist within the provider domain)
- IPv4 translation realm overlap support (can reuse IP addresses
between zones with some impact to extranet service model)
- Simple failover techniques can be implemented with redundant
translators, such as using a second default route
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Performance</span>
The MPLS/VPN CGN model was observed to support basic functions that
are typically used by subscribers within an operator environment. A
full review of the observed impacts related to CGN (NAT444) are
covered in [<a href="./rfc7021" title=""Assessing the Impact of Carrier-Grade NAT on Network Applications"">RFC7021</a>].
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
An operator implementing CGN using BGP/MPLS IP VPNs should refer to
<a href="./rfc6888#section-7">Section 7 of [RFC6888]</a> for security considerations related to CGN
deployments. The operator should continue to employ the standard
security methods in place for their standard MPLS deployment and can
also refer to the Security Considerations section in [<a href="./rfc4364" title=""BGP/MPLS IP Virtual Private Networks (VPNs)"">RFC4364</a>], which
discusses both control-plane and data-plane security.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. BGP/MPLS IP VPN CGN Framework Discussion</span>
The MPLS/VPN delivery method for a CGN deployment is an effective and
scalable way to deliver mass translation services. The architecture
avoids the complex requirements of traffic engineering and policy-
based routing when combining these new service flows to existing IPv4
<span class="grey">Kuarsingh & Cianfarani Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
operation. This is advantageous since the NAT444/CGN environments
should be introduced with as little impact as possible, and these
environments are expected to change over time.
The MPLS/VPN-based CGN architecture solves many of the issues related
to deploying this technology in existing operator networks.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Thanks to the following people for their comments and feedback: Dan
Wing, Chris Metz, Chris Donley, Tina TSOU, Christopher Liljenstolpe,
and Tom Taylor.
Thanks to the following people for their participation in integrating
and testing the CGN environment and for their guidance in regard to
IPv6 transition: Syd Alam, Richard Lawson, John E. Spence, John Jason
Brzozowski, Chris Donley, Jason Weil, Lee Howard, and Jean-Francois
Tremblay.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative Reference</span>
[<a id="ref-RFC4364">RFC4364</a>] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", <a href="./rfc4364">RFC 4364</a>, February 2006.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-CGN-DEPLOYMENTS">CGN-DEPLOYMENTS</a>]
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", Work in
Progress, January 2014.
[<a id="ref-RFC1918">RFC1918</a>] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", <a href="https://www.rfc-editor.org/bcp/bcp5">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp5">5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.
[<a id="ref-RFC3031">RFC3031</a>] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", <a href="./rfc3031">RFC 3031</a>, January 2001.
[<a id="ref-RFC5332">RFC5332</a>] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
Multicast Encapsulations", <a href="./rfc5332">RFC 5332</a>, August 2008.
[<a id="ref-RFC6037">RFC6037</a>] Rosen, E., Cai, Y., and IJ. Wijnands, "Cisco Systems'
Solution for Multicast in BGP/MPLS IP VPNs", <a href="./rfc6037">RFC 6037</a>,
October 2010.
<span class="grey">Kuarsingh & Cianfarani Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7289">RFC 7289</a> CGN Deployment with BGP/MPLS IP VPNs June 2014</span>
[<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-RFC6264">RFC6264</a>] Jiang, S., Guo, D., and B. Carpenter, "An Incremental
Carrier-Grade NAT (CGN) for IPv6 Transition", <a href="./rfc6264">RFC 6264</a>,
June 2011.
[<a id="ref-RFC6333">RFC6333</a>] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", <a href="./rfc6333">RFC 6333</a>, August 2011.
[<a id="ref-RFC6513">RFC6513</a>] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", <a href="./rfc6513">RFC 6513</a>, February 2012.
[<a id="ref-RFC6598">RFC6598</a>] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
Space", <a href="https://www.rfc-editor.org/bcp/bcp153">BCP 153</a>, <a href="./rfc6598">RFC 6598</a>, April 2012.
[<a id="ref-RFC6888">RFC6888</a>] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common Requirements for Carrier-Grade NATs
(CGNs)", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>, <a href="./rfc6888">RFC 6888</a>, April 2013.
[<a id="ref-RFC7021">RFC7021</a>] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J.
Doshi, "Assessing the Impact of Carrier-Grade NAT on
Network Applications", <a href="./rfc7021">RFC 7021</a>, September 2013.
Authors' Addresses
Victor Kuarsingh (editor)
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
EMail: victor@jvknet.com
URI: <a href="http://www.rogers.com">http://www.rogers.com</a>
John Cianfarani
Rogers Communications
8200 Dixie Road
Brampton, Ontario L6T 0C1
Canada
EMail: john.cianfarani@rci.rogers.com
URI: <a href="http://www.rogers.com">http://www.rogers.com</a>
Kuarsingh & Cianfarani Informational [Page 20]
</pre>
|
