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
|
<pre>Internet Engineering Task Force (IETF) G. Chen
Request for Comments: 7445 H. Deng
Category: Informational China Mobile
ISSN: 2070-1721 D. Michaud
Rogers Communications
J. Korhonen
Broadcom Corporation
M. Boucadair
France Telecom
March 2015
<span class="h1">Analysis of Failure Cases in IPv6 Roaming Scenarios</span>
Abstract
This document identifies a set of failure cases that may be
encountered by IPv6-enabled mobile customers in roaming scenarios.
The analysis reveals that the failure causes include improper
configurations, incomplete functionality support in equipment, and
inconsistent IPv6 deployment strategies between the home and the
visited networks.
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/rfc7445">http://www.rfc-editor.org/info/rfc7445</a>.
<span class="grey">Chen, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Background . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1">2.1</a>. Roaming Architecture: An Overview . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1.1">2.1.1</a>. Home Routed Mode . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.1.2">2.1.2</a>. Local Breakout Mode . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Typical Roaming Scenarios . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3">3</a>. Failure Case in the Network Attachment . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-4">4</a>. Failure Cases in the PDP/PDN Creation . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.1">4.1</a>. Case 1: Splitting Dual-Stack Bearer . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4.2">4.2</a>. Case 2: IPv6 PDP/PDN Unsupported . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.3">4.3</a>. Case 3: Inappropriate Roaming APN Set . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-4.4">4.4</a>. Case 4: Fallback Failure . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5">5</a>. Failure Cases in the Service Requests . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.1">5.1</a>. Lack of IPv6 Support in Applications . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2">5.2</a>. 464XLAT Support . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6">6</a>. HLR/HSS User Profile Setting . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7">7</a>. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-8">8</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<span class="grey">Chen, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Many mobile operators have deployed IPv6, or are about to, in their
operational networks. A customer in such a network can be provided
IPv6 connectivity if their User Equipment (UE) is IPv6 compliant.
Operators may adopt various approaches to deploy IPv6 in mobile
networks, such as the solutions described in [<a href="#ref-TR23.975" title=""IPv6 migration guidelines"">TR23.975</a>]. Depending
on network conditions, either dual-stack or IPv6-only deployment
schemes can be enabled.
A detailed overview of IPv6 support in 3GPP architectures is provided
in [<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>].
It has been observed and reported that a mobile subscriber roaming
around a different operator's areas may experience service disruption
due to inconsistent configurations and incomplete functionality of
equipment in the network. This document focuses on these issues.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>
This document makes use of these terms:
o Mobile networks refer to 3GPP mobile networks.
o Mobile UE denotes a 3GPP device that can be connected to 3GPP
mobile networks.
o The Public Land Mobile Network (PLMN) is a network that is
operated by a single administrative entity. A PLMN (and therefore
also an operator) is identified by the Mobile Country Code (MCC)
and the Mobile Network Code (MNC). Each (telecommunications)
operator providing mobile services has its own PLMN [<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>].
o The Home Location Register (HLR) is a pre-Release 5 database (but
is also used in real deployments of Release 5 and later) that
contains subscriber data and information related to call routing.
All subscribers of an operator and the subscribers' enabled
services are provisioned in the HLR [<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>].
o The Home Subscriber Server (HSS) is a database for a given
subscriber and was introduced in 3GPP Release 5. It is the entity
containing the subscription-related information to support the
network entities actually handling calls/sessions [<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>].
o "HLR/HSS" is used collectively for the subscriber database unless
referring to the failure case related to General Packet Radio
Service (GPRS) Subscriber data from the HLR.
<span class="grey">Chen, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
An overview of key 3GPP functional elements is documented in
[<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>].
"Mobile device" and "mobile UE" are used interchangeably.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Background</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Roaming Architecture: An Overview</span>
Roaming occurs in two scenarios:
o International roaming: a mobile UE enters a visited network
operated by a different operator, where a different PLMN code is
used. The UEs could, either in an automatic mode or in a manual
mode, attach to the visited PLMN.
o Intra-PLMN mobility: an operator may have one or multiple PLMN
codes. A mobile UE could pre-configure the codes to identify the
Home PLMN (HPLMN) or Equivalent HPLMN (EHPLMN). Intra-PLMN
mobility allows the UE to move to a different area of HPLMN and
EHPLMN. When the subscriber profile is not stored in the visited
area, HLR/HSS in the Home area will transmit the profile to the
Serving GPRS Support Node (SGSN) / Mobility Management Entity
(MME) in the visited area so as to complete network attachment.
When a UE is turned on or is transferred via a handover to a visited
network, the mobile device will scan all radio channels and find
available PLMNs to attach to. The SGSN or the MME in the visited
networks must contact the HLR or HSS to retrieve the subscriber
profile.
Steering of roaming may also be used by the HPLMN to further restrict
which of the available networks the UE may be attached to. Once the
authentication and registration stage is completed, the Packet Data
Protocol (PDP) or Packet Data Networks (PDN) activation and traffic
flows may be operated differently according to the subscriber profile
stored in the HLR or the HSS.
The following subsections describe two roaming modes: Home-routed
traffic (<a href="#section-2.1.1">Section 2.1.1</a>) and Local breakout (<a href="#section-2.1.2">Section 2.1.2</a>).
<span class="h4"><a class="selflink" id="section-2.1.1" href="#section-2.1.1">2.1.1</a>. Home Routed Mode</span>
In this mode, the subscriber's UE gets IP addresses from the home
network. All traffic belonging to that UE is therefore routed to the
home network (Figure 1).
<span class="grey">Chen, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
GPRS roaming exchange (GRX) or Internetwork Packet Exchange (IPX)
networks [<a href="#ref-IR.34" title=""Guidelines for IPX Provider networks"">IR.34</a>] are likely to be invoked as the transit network to
deliver the traffic. This is the main mode for international roaming
of Internet data services to facilitate the charging process between
the two involved operators.
+-----------------------------+ +------------------------+
|Visited Network | |Home Network |
| +----+ +----+---+ | (GRX/IPX) | +--------+ Traffic Flow
| | UE |=======>|SGSN/SGW|====================>|GGSN/PGW|============>
| +----+ +----+---+ | | +--------+ |
| |MME | | | |
| +----+ | Signaling | +--------+ |
| |-------------------------->|HLR/HSS | |
| | | +--------+ |
+-----------------------------+ +------------------------+
Figure 1: Home Routed Traffic
<span class="h4"><a class="selflink" id="section-2.1.2" href="#section-2.1.2">2.1.2</a>. Local Breakout Mode</span>
In the local breakout mode, IP addresses are assigned by the visited
network to a roaming mobile UE. Unlike the home routed mode, the
traffic doesn't have to traverse GRX/IPX; it is offloaded locally at
a network node close to that device's point of attachment in the
visited network. This mode ensures a more optimized forwarding path
for the delivery of packets belonging to a visiting UE (Figure 2).
+----------------------------+ +----------------+
|Visited Network | |Home Network |
| +----+ +--------+ | Signaling | +--------+ |
| | UE |=======>|SGSN/MME|------------------->|HLR/HSS | |
| +----+ +---+----+ | (GRX/IPX) | +--------+ |
| |SGW| | | |
| +---+ | | |
| || | | |
| +--------+ | | |
| |GGSN/PGW| | | |
| +--------+ | | |
| Traffic Flow || | | |
+------------------||--------+ +----------------+
\/
Figure 2: Local Breakout
The international roaming of services based on the IP Multimedia
Subsystem (IMS), e.g., Voice over LTE (VoLTE)[<a href="#ref-IR.92" title=""IMS Profile for Voice and SMS"">IR.92</a>], is claimed to
select the local breakout mode in [<a href="#ref-IR.65" title=""IMS Roaming and Interworking Guidelines"">IR.65</a>]. Data service roaming
<span class="grey">Chen, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
across different areas within an operator network might use local
breakout mode in order to get more efficient traffic forwarding and
also ease emergency services. The local breakout mode could also be
applied to an operator's alliance for international roaming of data
service.
EU Roaming Regulation III [<a href="#ref-EU-Roaming-III">EU-Roaming-III</a>] involves local breakout
mode allowing European subscribers roaming in European 2G/3G networks
to have their Internet data routed directly to the Internet from
their current Visited Public Land Mobile Network (VPLMN).
Specific local breakout-related configuration considerations are
listed below:
o Operators may add the APN-OI-Replacement flag defined in 3GPP
[<a href="#ref-TS29.272" title=""Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00"">TS29.272</a>] into the user's subscription data. The visited network
indicates a local domain name to replace the user requested Access
Point Name (APN). Consequently, the traffic would be steered to
the visited network. Those functions are normally deployed for
the intra-PLMN mobility cases.
o Operators may also configure the VPLMN-Dynamic-Address-Allowed
flag [<a href="#ref-TS29.272" title=""Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00"">TS29.272</a>] in the user's profile to enable local breakout
mode in VPLMNs.
o 3GPP specified the Selected IP Traffic Offload (SIPTO) function
[<a href="#ref-TS23.401" title=""General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access v9.00"">TS23.401</a>] since Release 10 in order to get efficient route paths.
It enables an operator to offload a portion of the traffic at a
network node close to the UE's point of attachment to the network.
o The Global System for Mobile Communications Association (GSMA) has
defined Roaming Architecture for Voice over LTE with Local
Breakout (RAVEL) [<a href="#ref-IR.65" title=""IMS Roaming and Interworking Guidelines"">IR.65</a>] as the IMS international roaming
architecture. Local breakout mode has been adopted for the IMS
roaming architecture.
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Typical Roaming Scenarios</span>
Three stages occur when a subscriber roams to a visited network and
intends to invoke services:
o Network attachment: this occurs when the UE enters a visited
network. During the attachment phase, the visited network should
authenticate the subscriber and make a location update to the
HSS/HLR in the home network of the subscriber. Accordingly, the
subscriber profile is offered from the HSS/HLR. The subscriber
profile contains the allowed APNs, the allowed PDP/PDN Types, and
rules regarding the routing of data sessions (i.e., home routed or
<span class="grey">Chen, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
local breakout mode) [<a href="#ref-TS29.272" title=""Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol v9.00"">TS29.272</a>]. The SGSN/MME in the visited
network can use this information to facilitate the subsequent
PDP/PDN session creation.
o PDP/PDN context creation: this occurs after the subscriber's UE
has been successfully attached to the network. This stage is
integrated with the attachment stage in the case of 4G, but is a
separate process in 2G/3G. 3GPP specifies three types of PDP/PDN
to describe connections: PDP/PDN Type IPv4, PDP/PDN Type IPv6, and
PDP/PDN Type IPv4v6. When a subscriber creates a data session,
their device requests a particular PDP/PDN Type. The allowed
PDP/PDN Types for that subscriber are learned in the attachment
stage. Hence, the SGSN and MME via the Serving Gateway (SGW)
could initiate a PDP/PDN request to Gateway GSN (GGSN) / Packet
Data Network Gateway (PGW) modulo subscription grants.
o Service requests: when the PDP/PDN context is created
successfully, UEs may launch applications and request services
based on the allocated IP addresses. The service traffic will be
transmitted via the visited network.
Failures that occur at the attachment stage (<a href="#section-3">Section 3</a>) are
independent of home routed and the local breakout modes. Most
failure cases in the PDP/PDN context creation (<a href="#section-4">Section 4</a>) and in
service requests (<a href="#section-5">Section 5</a>) occur in the local breakout mode.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Failure Case in the Network Attachment</span>
3GPP specified PDP/PDN Type IPv4v6 in order to allow a UE to get both
an IPv4 address and an IPv6 prefix within a single PDP/PDN bearer.
This option is stored as a part of subscription data for a subscriber
in the HLR/HSS. PDP/PDN Type IPv4v6 has been introduced at the
inception of the Evolved Packet System (EPS) in 4G networks.
The nodes in 4G networks should present no issues with the handling
of this PDN Type. However, the level of support varies in 2G/3G
networks depending on the SGSN software version. In theory, S4-SGSN
(i.e., an SGSN with S4 interface) has supported the PDP/PDN Type
IPv4v6 since Release 8, and Gn-SGSN (i.e., the SGSN with Gn
interface) has supported it since Release 9. In most cases,
operators normally use Gn-SGSN to connect either GGSN in 3G or Packet
Data Network Gateway (PGW) in 4G.
The MAP (Mobile Application Part) protocol, as defined in 3GPP
[<a href="#ref-TS29.002" title=""Mobile Application Part (MAP) specification v9.12.0"">TS29.002</a>], is used over the Gr interface between SGSN and HLR. The
MAP Information Element (IE) "ext-pdp-Type" contains the IPv4v6 PDP
Type that is conveyed to SGSN from the HLR within the Insert
Subscriber Data (ISD) MAP operation. If the SGSN does not support
<span class="grey">Chen, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
the IPv4v6 PDP Type, it will not support the "ext-pdp-Type" IE;
consequently, it must silently discard that IE and continue
processing the rest of the ISD MAP message. An issue that has been
observed is that multiple SGSNs are unable to correctly process a
subscriber's data received in the Insert Subscriber Data Procedure
[<a href="#ref-TS23.060" title=""General Packet Radio Service (GPRS); Service description; Stage 2 v9.00"">TS23.060</a>]. As a consequence, it will likely discard the subscriber
attach request. This is erroneous behavior due to the equipment not
being compliant with 3GPP Release 9.
In order to avoid encountering this attach problem at a visited SGSN,
both operators should make a comprehensive roaming agreement to
support IPv6 and ensure that it aligns with the GSMA documents, e.g.,
[<a href="#ref-IR.33" title=""GPRS Roaming Guidelines"">IR.33</a>], [<a href="#ref-IR.88" title=""LTE Roaming Guidelines"">IR.88</a>], and [<a href="#ref-IR.21" title=""Roaming Database, Structure and Updating Procedures"">IR.21</a>]. Such an agreement requires the
visited operator to get the necessary patch on all its SGSN nodes to
support the "ext-pdp-Type" MAP IE sent by the HLR. To ensure data-
session continuity in Radio Access Technology (RAT) handovers, the
PDN Type sent by the HSS to the MME should be consistent with the PDP
Type sent by the HLR to the Gn-SGSN. Where roaming agreements and
visited SGSN nodes have not been updated, the HPLMN also has to make
use of specific implementations (not standardized by 3GPP, discussed
further in <a href="#section-6">Section 6</a>) in the HLR/HSS of the home network. That is,
when the HLR/HSS receives an Update Location message from a visited
SGSN not known to support dual-stack in a single bearer, subscription
data allowing only PDP/PDN Type IPv4 or IPv6 will be sent to that
SGSN in the Insert Subscriber Data procedure. This guarantees that
the user profile is compatible with the visited SGSN/MME capability.
In addition, HSS may not have to change if the PGW is aware of the
subscriber's roaming status and only restricts the accepted PDN Type
consistent with PDP Type sent by the HLR. For example, a AAA server
may coordinate with the PGW to decide the allowed PDN Type.
Alternatively, HPLMNs without the non-standardized capability to
suppress the sending of "ext-pdp-Type" by the HLR may have to remove
this attribute from APNs with roaming service. PDN Type IPv4v6 must
also be removed from the corresponding profile for the APN in the
HSS. This will restrict their roaming UEs to only IPv4 or IPv6
PDP/PDN activation. This alternative has problems:
o The HPLMN cannot support dual-stack in a single bearer at home
where the APN profile in the HLR/HSS is also used for roaming.
o The UE may set up separate parallel bearers for IPv4 and IPv6,
where only single-stack IPv4 or IPv6 service is preferred by the
operator.
<span class="grey">Chen, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Failure Cases in the PDP/PDN Creation</span>
When a subscriber's UE succeeds in the attach stage, the IP
allocation process takes place to retrieve IP addresses. In general,
a PDP/PDN Type IPv4v6 request implicitly allows the network side to
make several IP assignment options, including IPv4-only, IPv6-only,
IPv4 and IPv6 in single PDP/PDN bearer, and IPv4 and IPv6 in
separated PDP/PDN bearers.
A PDP/PDN Type IPv4 or IPv6 restricts the network side to only
allocate the requested IP address family.
This section summarizes several failures in the Home Routed (HR) and
Local Breakout (LBO) mode as shown in Table 1.
+-------+-------------+------------------------+---------+
| Case# | UE request | PDP/PDN IP Type | Mode |
| | | permitted on GGSN/PGW | |
+-------+-------------+------------------------+---------+
| | IPv4v6 | IPv4v6 | HR |
| #1 |-------------+------------------------+---------+
| | IPv4v6 | IPv4 or IPv6 | LBO |
+-------+-------------+------------------------+---------+
| #2 | IPv6 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #3 | IPv4 | IPv6 | HR |
+-------+-------------+------------------------+---------+
| #4 | IPv6 | IPv4 | LBO |
+-------+-------------+------------------------+---------+
Table 1: Failure Cases in the PDP/PDN Creation
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Case 1: Splitting Dual-Stack Bearer</span>
Dual-stack capability is provided using separate PDP/PDN activation
in the visited network that doesn't support PDP/PDN Type IPv4v6.
That means only separate, parallel, single-stack IPv4 and IPv6
PDP/PDN connections are allowed to be initiated to separately
allocate an IPv4 address and an IPv6 prefix. The SGSN does not
support the Dual Address Bearer Flag (DAF) or does not set the DAF
because the operator uses single addressing per bearer to support
interworking with nodes of earlier releases. Regardless of home
routed or local breakout mode, GGSN/PGW will change PDN/PDP Type to a
single address PDP/PDN Type and return the Session Management (SM)
Cause #52 "single address bearers only allowed" or SM Cause #28
"unknown PDP address or PDP type" as per [<a href="#ref-TS24.008" title=""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 v9.00"">TS24.008</a>] and [<a href="#ref-TS24.301" title=""Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS) ; Stage 3 v9.00"">TS24.301</a>] to
<span class="grey">Chen, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
the UE. In this case, the UE may make another PDP/PDN request with a
single address PDP Type (IPv4 or IPv6) other than the one already
activated.
This approach suffers from the following drawbacks:
o The parallel PDP/PDN activation would likely double PDP/PDN bearer
resource on the network side and Radio Access Bearer (RAB)
resource on the Radio Access Network (RAN) side. It also impacts
the capacity of the GGSN/PGW, since only a certain amount of
PDP/PDN activation is allowed on those nodes.
o Some networks may allow only one PDP/PDN to be alive for each
subscriber. For example, an IPv6 PDP/PDN will be rejected if the
subscriber has an active IPv4 PDP/PDN. Therefore, the subscriber
would not be able to obtain the IPv6 connection in the visited
network. It is even worse, as they may have a risk of losing all
data connectivity if the IPv6 PDP gets rejected with a permanent
error at the APN level and not an error specific to the PDP-Type
IPv6 requested.
o Additional correlations between those two PDP/PDN contexts are
required on the charging system.
o Policy and Charging Rules Function (PCRF) [<a href="#ref-TS29.212" title=""Policy and Charging Control (PCC); Reference points v9.0.0"">TS29.212</a>] / Policy and
Charging Enforcement Function (PCEF) treats the IPv4 and IPv6
sessions as independent and performs different quality-of-service
(QoS) policies. The subscriber may have an unstable experience
due to different behaviors on each IP version connection.
o Mobile devices may have a limitation on the number of allowed
simultaneous PDP/PDN contexts. Excessive PDP/PDN activations may
result in service disruption.
In order to avoid the issue, the roaming agreement in the home routed
mode should make sure the visited SGSN supports and sets the DAF.
Since the PDP/PDN Type IPv4v6 is supported in the GGSN/PGW of the
home network, it's expected that the visited SGSN/MME could create a
dual-stack bearer as the UE requested.
In the local breakout mode, the visited SGSN may only allow single IP
version addressing. In this case, the DAF on the visited SGSN/MME
has to be unset. One approach is to set a dedicated APN [<a href="#ref-TS23.003" title=""Numbering, addressing and identification v9.0.0"">TS23.003</a>]
profile to only request PDP/PDN Type IPv4 in the roaming network.
Some operators may also consider not adopting the local breakout mode
to avoid the risks.
<span class="grey">Chen, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Case 2: IPv6 PDP/PDN Unsupported</span>
PDP/PDN Type IPv6 has good compatibility to visited networks during
the network attachment. In order to support the IPv6-only visitors,
SGSN/MME in the visited network is required to accept IPv6-only
PDP/PDN activation requests and enable IPv6 on the user plane in the
direction of the home network.
In some cases, IPv6-only visitors may still be subject to the SGSN
capability in visited networks. This becomes especially risky if the
home operator performs roaming steering targeted to an operator that
doesn't allow IPv6. The visited SGSN may just directly reject the
PDP context activation. Therefore, it's expected that the visited
network is IPv6 roaming-friendly to enable the functions on SGSN/MME
by default. Otherwise, operators may consider steering the roaming
traffic to the IPv6-enabled visited network that has an IPv6 roaming
agreement.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Case 3: Inappropriate Roaming APN Set</span>
If IPv6 single stack with the home routed mode is deployed, the
requested PDP/PDN Type should also be IPv6. Some implementations
that support the roaming APN profile may set IPv4 as the default
PDP/PDN Type, since the visited network is incapable of supporting
PDP/PDN Types IPv4v6 (<a href="#section-4.1">Section 4.1</a>) and IPv6 (<a href="#section-4.2">Section 4.2</a>). The
PDP/PDN request will fail because the APN in the home network only
allows IPv6. Therefore, the roaming APNs have to be compliant with
the home network configuration when home routed mode is adopted.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. Case 4: Fallback Failure</span>
In the local breakout mode, PDP/PDN Type IPv6 should have no issues
to pass through the network attachment process, since 3GPP specified
the PDP/PDN Type IPv6 as early as PDP/PDN Type IPv4. When a visitor
requests PDP/PDN Type IPv6, the network should only return the
expected IPv6 prefix. The UE may fail to get an IPv6 prefix if the
visited network only allocates an IPv4 address. In this case, the
visited network will reject the request and send the cause code to
the UE.
A proper fallback scheme for PDP/PDN Type IPv6 is desirable; however,
there is no standard way to specify this behavior. The roaming APN
profile could help to address the issue by setting the PDP/PDN Type
to IPv4. For instance, the Android system solves the issue by
configuring the roaming protocol to IPv4 for the APN. It guarantees
that UE will always initiate a PDP/PDN Type IPv4 in the roaming area.
<span class="grey">Chen, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Failure Cases in the Service Requests</span>
After the successful network attachment and IP address allocation,
applications could start to request service based on the activated
PDP/PDN context. The service request may depend on specific IP
family or network collaboration. If traffic is offloaded locally
(<a href="#section-2.1.2">Section 2.1.2</a>), the visited network may not be able to accommodate
the UE's service requests. This section describes the failures.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Lack of IPv6 Support in Applications</span>
Operators may only allow IPv6 in the IMS APN. VoLTE [<a href="#ref-IR.92" title=""IMS Profile for Voice and SMS"">IR.92</a>] and Rich
Communication Suite (RCS) [<a href="#ref-RCC.07" title=""Rich Communication Suite 5.2 Advanced Communications Services and Client Specification"">RCC.07</a>] use the APN to offer voice service
for visitors. The IMS roaming in RAVEL architecture [<a href="#ref-IR.65" title=""IMS Roaming and Interworking Guidelines"">IR.65</a>] offloads
voice and video traffic in the visited network; therefore, a dual-
stack visitor can only be assigned with an IPv6 prefix but no IPv4
address. If the applications can't support IPv6, the service is
likely to fail.
Translation-based methods, for example, 464XLAT [<a href="./rfc6877" title=""464XLAT: Combination of Stateful and Stateless Translation"">RFC6877</a>] or Bump-in-
the-Host (BIH) [<a href="./rfc6535" title=""Dual-Stack Hosts Using "">RFC6535</a>], may help to address the issue if there are
IPv6 compatibility problems. The translation function could be
enabled in an IPv6-only network and disabled in a dual-stack or IPv4
network; therefore, the IPv4 applications only get the translation in
the IPv6 network and they perform normally in an IPv4 or dual-stack
network.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. 464XLAT Support</span>
464XLAT [<a href="./rfc6877" title=""464XLAT: Combination of Stateful and Stateless Translation"">RFC6877</a>] is proposed to address the IPv4 compatibility issue
in an IPv6-only connectivity environment. The customer-side
translator (CLAT) function on a mobile device is likely used in
conjunction with a PDP/PDN IPv6 Type request and cooperates with a
remote NAT64 [<a href="./rfc6146" title=""Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers"">RFC6146</a>] device.
464XLAT may use the mechanism defined in [<a href="./rfc7050" title=""Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis"">RFC7050</a>] or [<a href="./rfc7225" title=""Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)"">RFC7225</a>] to
detect the presence of NAT64 devices and to learn the IPv6 prefix
used for protocol translation [<a href="./rfc6052" title=""IPv6 Addressing of IPv4/IPv6 Translators"">RFC6052</a>].
In the local breakout approach, a UE with the 464XLAT function
roaming on an IPv6 visited network may encounter various situations.
For example, the visited network may not have deployed DNS64
[<a href="./rfc6147" title=""DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers"">RFC6147</a>] but only NAT64, or CLAT may not be able to discover the
provider-side translator (PLAT) translation IPv6 prefix used as a
destination of the PLAT. If the visited network doesn't have a NAT64
and DNS64 deployed, 464XLAT can't perform successfully due to the
<span class="grey">Chen, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
lack of PLAT collaboration. Even in the case of the presence of
NAT64 and DNS64, a pre-configured PLAT IPv6 prefix in the CLAT may
cause failure because it can't match the PLAT translation.
Considering the various network configurations, operators may turn
off local breakout and use the home routed mode to perform 464XLAT.
Alternatively, UE may support the different roaming profile
configuration to adopt 464XLAT in the home network and use IPv4-only
in the visited networks.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. HLR/HSS User Profile Setting</span>
A proper user profile configuration would provide a deterministic
outcome to the PDP/PDN creation stage where dual-stack, IPv4-only,
and IPv6-only connectivity requests may come from devices. The
HLR/HSS may have to apply extra logic (not standardized by 3GPP) to
achieve this. It is also desirable that the network be able to set
up connectivity of any requested PDP/PDN context type.
The following are examples to illustrate the settings for the
scenarios and the decision criteria to be applied when returning user
profile information from the HLR to the visited SGSN.
user profile #1:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv6
....
}
Scenario 1: Support of IPv6-Only, IPv4-Only, and Dual-Stack Devices
<span class="grey">Chen, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
The full PDP-context parameters are referred to <a href="#section-17.7.1">Section 17.7.1</a>
("Mobile Service data types") of [<a href="#ref-TS29.002" title=""Mobile Application Part (MAP) specification v9.12.0"">TS29.002</a>]. User profiles #1 and #2
share the same "ContextId". The setting of user profile #1 enables
IPv4-only and dual-stack devices to work. User profile #2 fulfills
the request if the device asks for IPv6-only PDP context.
user profile #1:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
ext-pdp-Type PDP-Type-IPv4v6
...
}
user profile #2:
PDP-Context ::= SEQUENCE {
pdp-ContextId ContextId,
pdp-Type PDP-Type-IPv4
....
}
Scenario 2: Support of Dual-Stack Devices with Pre-Release 9 Visited
SGSN (vSGSN) Access
User profiles #1 and #2 share the same "ContextId". If a visited
SGSN is identified as early as pre-Release 9, the HLR/HSS should only
send user profile #2 to the visited SGSN.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Discussion</span>
Several failure cases have been discussed in this document. It has
been illustrated that the major problems happen at three stages: the
initial network attachment, the PDP/PDN creation, and service
requests.
In the network attachment stage, PDP/PDN Type IPv4v6 is the major
concern to the visited pre-Release 9 SGSN. 3GPP didn't specify
PDP/PDN Type IPv4v6 in the earlier releases. That PDP/PDN Type is
supported in the newly built EPS network, but it isn't supported well
in the third-generation network. Visited SGSNs may discard the
subscriber's attach requests because the SGSN is unable to correctly
process PDP/PDN Type IPv4v6. Operators may have to adopt temporary
<span class="grey">Chen, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
solutions unless all the interworking nodes (i.e., the SGSN) in the
visited network have been upgraded to support the ext-PDP-Type
feature.
In the PDP/PDN creation stage, support of PDP/PDN Types IPv4v6 and
IPv6 on the visited SGSN is the major concern. It has been observed
that single-stack IPv6 in the home routed mode is a viable approach
to deploy IPv6. It is desirable that the visited SGSN have the
ability to enable IPv6 on the user plane by default. For support of
the PDP/PDN Type IPv4v6, it is suggested to set the DAF. As a
complementary function, the implementation of a roaming APN
configuration is useful to accommodate the visited network. However,
it should consider roaming architecture and the permitted PDP/PDN
Type to properly set the UE. Roaming APN in the home routed mode is
recommended to align with home network profile setting. In the local
breakout case, PDP/PDN Type IPv4 could be selected as a safe way to
initiate PDP/PDN activation.
In the service requests stage, the failure cases mostly occur in the
local breakout case. The visited network may not be able to satisfy
the requested capability from applications or UEs. Operators may
consider using home routed mode to avoid these problems. Several
solutions, in either the network side or mobile device side, can also
help to address the issue. For example,
o 464XLAT could help IPv4 applications access IPv6 visited networks.
o Networks can deploy a AAA server to coordinate the mobile device
capability. Once the GGSN/PGW receives the session creation
request, it will initiate a request to a AAA server in the home
network via the RADIUS or Diameter protocol [<a href="#ref-TS29.061" title=""Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN) v9.14.0"">TS29.061</a>]. The
request contains subscriber and visited network information, e.g.,
PDP/PDN Type, International Mobile Equipment Identity (IMEI),
Software Version (SV) and visited SGSN/MME location code, etc.
The AAA server could take mobile device capability and combine it
with the visited network information to ultimately determine the
type of session to be created, i.e., IPv4, IPv6, or IPv4v6.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Security Considerations</span>
Although this document defines neither a new architecture nor a new
protocol, the reader is encouraged to refer to [<a href="./rfc6459" title=""IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)"">RFC6459</a>] for a
generic discussion on IPv6-related security considerations.
<span class="grey">Chen, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
<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 References</span>
[<a id="ref-IR.21">IR.21</a>] Global System for Mobile Communications Association
(GSMA), "Roaming Database, Structure and Updating
Procedures", IR.21, Version 7.4, November 2013.
[<a id="ref-IR.65">IR.65</a>] Global System for Mobile Communications Association
(GSMA), "IMS Roaming and Interworking Guidelines", IR.65,
Version 15.0, January 2015.
[<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 href="http://www.rfc-editor.org/info/rfc6146">http://www.rfc-editor.org/info/rfc6146</a>>.
[<a id="ref-RFC6147">RFC6147</a>] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", <a href="./rfc6147">RFC 6147</a>,
April 2011, <<a href="http://www.rfc-editor.org/info/rfc6147">http://www.rfc-editor.org/info/rfc6147</a>>.
[<a id="ref-RFC6877">RFC6877</a>] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", <a href="./rfc6877">RFC</a>
<a href="./rfc6877">6877</a>, April 2013,
<<a href="http://www.rfc-editor.org/info/rfc6877">http://www.rfc-editor.org/info/rfc6877</a>>.
[<a id="ref-TS23.060">TS23.060</a>] 3GPP, "General Packet Radio Service (GPRS); Service
description; Stage 2 v9.00", TS 23.060, March 2009.
[<a id="ref-TS23.401">TS23.401</a>] 3GPP, "General Packet Radio Service (GPRS) enhancements
for Evolved Universal Terrestrial Radio Access Network
(E-UTRAN) access v9.00", TS 23.401, March 2009.
[<a id="ref-TS29.002">TS29.002</a>] 3GPP, "Mobile Application Part (MAP) specification
v9.12.0", TS 29.002, December 2009.
[<a id="ref-TS29.272">TS29.272</a>] 3GPP, "Mobility Management Entity (MME) and Serving GPRS
Support Node (SGSN) related interfaces based on Diameter protocol
v9.00", TS 29.272, September 2009.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-EU-Roaming-III">EU-Roaming-III</a>]
Amdocs Inc., "Amdocs 2014 EU Roaming Regulation III
Solution", July 2013, <<a href="http://www.amdocs.com/Products/Revenue-Management/Documents/amdocs-eu-roaming-regulation-III-solution.pdf">http://www.amdocs.com/Products/</a>
<a href="http://www.amdocs.com/Products/Revenue-Management/Documents/amdocs-eu-roaming-regulation-III-solution.pdf">Revenue-Management/Documents/</a>
<a href="http://www.amdocs.com/Products/Revenue-Management/Documents/amdocs-eu-roaming-regulation-III-solution.pdf">amdocs-eu-roaming-regulation-III-solution.pdf</a>>.
<span class="grey">Chen, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
[<a id="ref-IR.33">IR.33</a>] Global System for Mobile Communications Association
(GSMA), "GPRS Roaming Guidelines", IR.33, Version 7.0,
June 2014.
[<a id="ref-IR.34">IR.34</a>] Global System for Mobile Communications Association
(GSMA), "Guidelines for IPX Provider networks", IR.34
Version 11.0, January 2015.
[<a id="ref-IR.88">IR.88</a>] Global System for Mobile Communications Association
(GSMA), "LTE Roaming Guidelines", IR.88, Version 12.0,
January 2015.
[<a id="ref-IR.92">IR.92</a>] Global System for Mobile Communications Association
(GSMA), "IMS Profile for Voice and SMS", IR.92, Version
7.1, January 2015.
[<a id="ref-RCC.07">RCC.07</a>] Global System for Mobile Communications Association
(GSMA), "Rich Communication Suite 5.2 Advanced
Communications Services and Client Specification", RCC.07,
Version 5.0, May 2014.
[<a id="ref-RFC6052">RFC6052</a>] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", <a href="./rfc6052">RFC 6052</a>,
October 2010, <<a href="http://www.rfc-editor.org/info/rfc6052">http://www.rfc-editor.org/info/rfc6052</a>>.
[<a id="ref-RFC6459">RFC6459</a>] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
<a href="./rfc6459">RFC 6459</a>, January 2012,
<<a href="http://www.rfc-editor.org/info/rfc6459">http://www.rfc-editor.org/info/rfc6459</a>>.
[<a id="ref-RFC6535">RFC6535</a>] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts
Using "Bump-in-the-Host" (BIH)", <a href="./rfc6535">RFC 6535</a>, February 2012,
<<a href="http://www.rfc-editor.org/info/rfc6535">http://www.rfc-editor.org/info/rfc6535</a>>.
[<a id="ref-RFC7050">RFC7050</a>] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", <a href="./rfc7050">RFC</a>
<a href="./rfc7050">7050</a>, November 2013,
<<a href="http://www.rfc-editor.org/info/rfc7050">http://www.rfc-editor.org/info/rfc7050</a>>.
[<a id="ref-RFC7225">RFC7225</a>] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the
Port Control Protocol (PCP)", <a href="./rfc7225">RFC 7225</a>, May 2014,
<<a href="http://www.rfc-editor.org/info/rfc7225">http://www.rfc-editor.org/info/rfc7225</a>>.
[<a id="ref-TR23.975">TR23.975</a>] 3GPP, "IPv6 migration guidelines", TR 23.975, June 2011.
[<a id="ref-TS23.003">TS23.003</a>] 3GPP, "Numbering, addressing and identification v9.0.0",
TS 23.003, September 2009.
<span class="grey">Chen, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
[<a id="ref-TS24.008">TS24.008</a>] 3GPP, "Mobile radio interface Layer 3 specification; Core
network protocols; Stage 3 v9.00", TS 24.008, September
2009.
[<a id="ref-TS24.301">TS24.301</a>] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved
Packet System (EPS) ; Stage 3 v9.00", TS 24.301, September
2009.
[<a id="ref-TS29.061">TS29.061</a>] 3GPP, "Interworking between the Public Land Mobile Network
(PLMN) supporting packet based services and Packet Data
Networks (PDN) v9.14.0", TS 29.061, January 2015.
[<a id="ref-TS29.212">TS29.212</a>] 3GPP, "Policy and Charging Control (PCC); Reference points
v9.0.0", TS 29.212, September 2009.
Acknowledgements
Many thanks to F. Baker and J. Brzozowski for their support.
This document is the result of the IETF v6ops IPv6-Roaming design
team effort.
The authors would like to thank Mikael Abrahamsson, Victor Kuarsingh,
Nick Heatley, Alexandru Petrescu, Tore Anderson, Cameron Byrne,
Holger Metschulat, and Geir Egeland for their helpful discussions and
comments.
The authors especially thank Fred Baker and Ross Chandler for their
efforts and contributions that substantially improved the readability
of the document.
Contributors
The following individual contributed to this document.
Vizdal Ales
Deutsche Telekom AG
Tomickova 2144/1
Prague 4, 149 00
Czech Republic
EMail: ales.vizdal@t-mobile.cz
<span class="grey">Chen, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7445">RFC 7445</a> IPv6 Roaming Analysis March 2015</span>
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xicheng District,
Beijing 100053
China
EMail: phdgang@gmail.com, chengang@chinamobile.com
Hui Deng
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
EMail: denghui@chinamobile.com
Dave Michaud
Rogers Communications
8200 Dixie Rd.
Brampton, ON L6T 0C1
Canada
EMail: dave.michaud@rci.rogers.com
Jouni Korhonen
Broadcom Corporation
3151 Zanker Rd.
San Jose, CA 95134
United States
EMail: jouni.nospam@gmail.com
Mohamed Boucadair
France Telecom
Rennes,
35000
France
EMail: mohamed.boucadair@orange.com
Chen, et al. Informational [Page 19]
</pre>
|
