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
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
|
<pre>Network Working Group C. Ng
Request for Comments: 4888 Panasonic Singapore Labs
Category: Informational P. Thubert
Cisco Systems
M. Watari
KDDI R&D Labs
F. Zhao
UC Davis
July 2007
<span class="h1">Network Mobility Route Optimization Problem Statement</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
With current Network Mobility (NEMO) Basic Support, all
communications to and from Mobile Network Nodes must go through the
bi-directional tunnel established between the Mobile Router and Home
Agent when the mobile network is away. This sub-optimal routing
results in various inefficiencies associated with packet delivery,
such as increased delay and bottleneck links leading to traffic
congestion, which can ultimately disrupt all communications to and
from the Mobile Network Nodes. Additionally, with nesting of Mobile
Networks, these inefficiencies get compounded, and stalemate
conditions may occur in specific dispositions. This document
investigates such problems and provides the motivation behind Route
Optimization (RO) for NEMO.
<span class="grey">Ng, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. NEMO Route Optimization Problem Statement . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a>. Sub-Optimality with NEMO Basic Support . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-2.2">2.2</a>. Bottleneck in the Home Network . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-2.3">2.3</a>. Amplified Sub-Optimality in Nested Mobile Networks . . . . <a href="#page-6">6</a>
2.4. Sub-Optimality with Combined Mobile IPv6 Route
Optimization . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
2.5. Security Policy Prohibiting Traffic from Visiting Nodes . 9
2.6. Instability of Communications within a Nested Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-2.7">2.7</a>. Stalemate with a Home Agent Nested in a Mobile Network . . <a href="#page-10">10</a>
<a href="#section-3">3</a>. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5">5</a>. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.1">6.1</a>. Normative Reference . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-6.2">6.2</a>. Informative Reference . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. Various Configurations Involving Nested Mobile
Networks . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.1">A.1</a>. CN Located in the Fixed Infrastructure . . . . . . . . . . <a href="#page-13">13</a>
<a href="#appendix-A.1.1">A.1.1</a>. Case A: LFN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.1.2">A.1.2</a>. Case B: VMN and MIPv6 CN . . . . . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.1.3">A.1.3</a>. Case C: VMN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-14">14</a>
<a href="#appendix-A.2">A.2</a>. CN Located in Distinct Nested NEMOs . . . . . . . . . . . <a href="#page-15">15</a>
<a href="#appendix-A.2.1">A.2.1</a>. Case D: LFN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A.2.2">A.2.2</a>. Case E: VMN and MIPv6 CN . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A.2.3">A.2.3</a>. Case F: VMN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#appendix-A.3">A.3</a>. MNN and CN Located in the Same Nested NEMO . . . . . . . . <a href="#page-17">17</a>
<a href="#appendix-A.3.1">A.3.1</a>. Case G: LFN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A.3.2">A.3.2</a>. Case H: VMN and MIPv6 CN . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#appendix-A.3.3">A.3.3</a>. Case I: VMN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-A.4">A.4</a>. CN Located Behind the Same Nested MR . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#appendix-A.4.1">A.4.1</a>. Case J: LFN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#appendix-A.4.2">A.4.2</a>. Case K: VMN and MIPv6 CN . . . . . . . . . . . . . . . <a href="#page-20">20</a>
<a href="#appendix-A.4.3">A.4.3</a>. Case L: VMN and Standard IPv6 CN . . . . . . . . . . . <a href="#page-21">21</a>
<a href="#appendix-B">Appendix B</a>. Example of How a Stalemate Situation Can Occur . . . <a href="#page-22">22</a>
<span class="grey">Ng, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
With current Network Mobility (NEMO) Basic Support [<a href="#ref-1" title=""Network Mobility (NEMO) Basic Support Protocol"">1</a>], all
communications to and from nodes in a mobile network must go through
the bi-directional tunnel established between the Mobile Router and
its Home Agent (also known as the MRHA tunnel) when the mobile
network is away. Although such an arrangement allows Mobile Network
Nodes to reach and be reached by any node on the Internet,
limitations associated to the base protocol degrade overall
performance of the network and, ultimately, can prevent all
communications to and from the Mobile Network Nodes.
Some of these concerns already exist with Mobile IPv6 [<a href="#ref-4" title=""Mobility Support in IPv6"">4</a>] and were
addressed by the mechanism known as Route Optimization, which is part
of the base protocol. With Mobile IPv6, Route Optimization mostly
improves the end-to-end path between the Mobile Node and
Correspondent Node, with an additional benefit of reducing the load
of the Home Network, thus its name.
NEMO Basic Support presents a number of additional issues, making the
problem more complex, so it was decided to address Route Optimization
separately. In that case, the expected benefits are more dramatic,
and a Route Optimization mechanism could enable connectivity that
would be broken otherwise. In that sense, Route Optimization is even
more important to NEMO Basic Support than it is to Mobile IPv6.
This document explores limitations inherent in NEMO Basic Support,
and their effects on communications between a Mobile Network Node and
its corresponding peer. This is detailed in <a href="#section-2">Section 2</a>. It is
expected that readers are familiar with general terminologies related
to mobility in [<a href="#ref-4" title=""Mobility Support in IPv6"">4</a>][2], NEMO-related terms defined in [<a href="#ref-3" title=""Network Mobility Support Terminology"">3</a>], and NEMO
goals and requirements [<a href="#ref-5" title=""Network Mobility Support Goals and Requirements"">5</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. NEMO Route Optimization Problem Statement</span>
Given the NEMO Basic Support protocol, all data packets to and from
Mobile Network Nodes must go through the Home Agent, even though a
shorter path may exist between the Mobile Network Node and its
Correspondent Node. In addition, with the nesting of Mobile Routers,
these data packets must go through multiple Home Agents and several
levels of encapsulation, which may be avoided. This results in
various inefficiencies and problems with packet delivery, which can
ultimately disrupt all communications to and from the Mobile Network
Nodes.
In the following sub-sections, we will describe the effects of a
pinball route with NEMO Basic Support, how it may cause a bottleneck
to be formed in the Home Network, and how these get amplified with
<span class="grey">Ng, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
nesting of mobile networks. Closely related to nesting, we will also
look into the sub-optimality even when Mobile IPv6 Route Optimization
is used over NEMO Basic Support. This is followed by a description
of security policy in the Home Network that may forbid transit
traffic from Visiting Mobile Nodes in mobile networks. In addition,
we will explore the impact of the MRHA tunnel on communications
between two Mobile Network Nodes on different links of the same
mobile network. We will also provide additional motivations for
Route Optimization by considering the potential stalemate situation
when a Home Agent is part of a mobile network.
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Sub-Optimality with NEMO Basic Support</span>
With NEMO Basic Support, all packets sent between a Mobile Network
Node and its Correspondent Node are forwarded through the MRHA
tunnel, resulting in a pinball route between the two nodes. This has
the following sub-optimal effects:
o Longer Route Leading to Increased Delay and Additional
Infrastructure Load
Because a packet must transit from a mobile network to the Home
Agent then to the Correspondent Node, the transit time of the
packet is usually longer than if the packet were to go straight
from the mobile network to the Correspondent Node. When the
Correspondent Node (or the mobile network) resides near the Home
Agent, the increase in packet delay can be very small. However,
when the mobile network and the Correspondent Node are relatively
near to one another but far away from the Home Agent on the
Internet, the increase in delay is very large. Applications such
as real-time multimedia streaming may not be able to tolerate such
increase in packet delay. In general, the increase in delay may
also impact the performance of transport protocols such as TCP,
since the sending rate of TCP is partly determined by the round-
trip time (RTT) perceived by the communication peers.
Moreover, by using a longer route, the total resource utilization
for the traffic would be much higher than if the packets were to
follow a direct path between the Mobile Network Node and
Correspondent Node. This would result in additional load in the
infrastructure.
o Increased Packet Overhead
The encapsulation of packets in the MRHA tunnel results in
increased packet size due to the addition of an outer header.
This reduces the bandwidth efficiency, as an IPv6 header can be
<span class="grey">Ng, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
quite substantial relative to the payload for applications such as
voice samples. For instance, given a voice application using an 8
kbps algorithm (e.g., G.729) and taking a voice sample every 20 ms
(as in <a href="./rfc1889">RFC 1889</a> [<a href="#ref-6" title=""RTP: A Transport Protocol for Real-Time Applications"">6</a>]), the packet transmission rate will be 50
packets per second. Each additional IPv6 header is an extra 320
bits per packet (i.e., 16 kbps), which is twice the actual
payload!
o Increased Processing Delay
The encapsulation of packets in the MRHA tunnel also results in
increased processing delay at the points of encapsulation and
decapsulation. Such increased processing may include encryption/
decryption, topological correctness verifications, MTU
computation, fragmentation, and reassembly.
o Increased Chances of Packet Fragmentation
The augmentation in packet size due to packet encapsulation may
increase the chances of the packet being fragmented along the MRHA
tunnel. This can occur if there is no prior path MTU discovery
conducted, or if the MTU discovery mechanism did not take into
account the encapsulation of packets. Packet fragmentation will
result in a further increase in packet delays and further
reduction of bandwidth efficiency.
o Increased Susceptibility to Link Failure
Under the assumption that each link has the same probability of
link failure, a longer routing path would be more susceptible to
link failure. Thus, packets routed through the MRHA tunnel may be
subjected to a higher probability of being lost or delayed due to
link failure, compared to packets that traverse directly between
the Mobile Network Node and its Correspondent Node.
<span class="grey">Ng, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Bottleneck in the Home Network</span>
Apart from the increase in packet delay and infrastructure load,
forwarding packets through the Home Agent may also lead to either the
Home Agent or the Home Link becoming a bottleneck for the aggregated
traffic from/to all the Mobile Network Nodes. A congestion at home
would lead to additional packet delay, or even packet loss. In
addition, Home Agent operations such as security check, packet
interception, and tunneling might not be as optimized in the Home
Agent software as plain packet forwarding. This could further limit
the Home Agent capacity for data traffic. Furthermore, with all
traffic having to pass through the Home Link, the Home Link becomes a
single point of failure for the mobile network.
Data packets that are delayed or discarded due to congestion at the
Home Network would cause additional performance degradation to
applications. Signaling packets, such as Binding Update messages,
that are delayed or discarded due to congestion at the Home Network
may affect the establishment or update of bi-directional tunnels,
causing disruption of all traffic flow through these tunnels.
A NEMO Route Optimization mechanism that allows the Mobile Network
Nodes to communicate with their Correspondent Nodes via a path that
is different from the MRHA tunneling and thereby avoiding the Home
Agent may alleviate or even prevent the congestion at the Home Agent
or Home Link.
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Amplified Sub-Optimality in Nested Mobile Networks</span>
By allowing other mobile nodes to join a mobile network, and in
particular mobile routers, it is possible to form arbitrary levels of
nesting of mobile networks. With such nesting, the use of NEMO Basic
Support further amplifies the sub-optimality of routing. We call
this the amplification effect of nesting, where the undesirable
effects of a pinball route with NEMO Basic Support are amplified with
each level of nesting of mobile networks. This is best illustrated
by an example shown in Figure 1.
<span class="grey">Ng, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +------------------------------+
| MR1_HA |----| Internet |-----CN1
+--------+ +------------------------------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN2
Figure 1: An Example of a Nested Mobile Network
Using NEMO Basic Support, the flow of packets between a Mobile
Network Node, MNN, and a Correspondent Node, CN1, would need to go
through three separate tunnels, illustrated in Figure 2 below.
----------.
---------/ /----------.
-------/ | | /-------
MNN -----( - - | - - - | - - - | - - - | - - (------ CN1
MR3-------\ | | \-------MR3_HA
MR2--------\ \----------MR2_HA
MR1---------MR1_HA
Figure 2: Nesting of Bi-Directional Tunnels
<span class="grey">Ng, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
This leads to the following problems:
o Pinball Route
Both inbound and outbound packets will flow via the Home Agents of
all the Mobile Routers on their paths within the mobile network,
with increased latency, less resilience, and more bandwidth usage.
<a href="#appendix-A">Appendix A</a> illustrates in detail the packets' routes under
different nesting configurations of the Mobile Network Nodes.
o Increased Packet Size
An extra IPv6 header is added per level of nesting to all the
packets. The header compression suggested in [<a href="#ref-7" title=""Redundant Address Deletion when Encapsulating IPv6 in IPv6"">7</a>] cannot be
applied because both the source and destination (the intermediate
Mobile Router and its Home Agent) are different hop to hop.
Nesting also amplifies the probability of congestion at the Home
Networks of the upstream Mobile Routers. In addition, the Home Link
of each upstream Mobile Router will also be a single point of failure
for the nested Mobile Router.
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Sub-Optimality with Combined Mobile IPv6 Route Optimization</span>
When a Mobile IPv6 host joins a mobile network, it becomes a Visiting
Mobile Node of the mobile network. Packets sent to and from the
Visiting Mobile Node will have to be routed not only via the Home
Agent of the Visiting Mobile Node, but also via the Home Agent of the
Mobile Router in the mobile network. This suffers the same
amplification effect of nested mobile network mentioned in
<a href="#section-2.3">Section 2.3</a>.
In addition, although Mobile IPv6 [<a href="#ref-4" title=""Mobility Support in IPv6"">4</a>] allows a mobile host to perform
Route Optimization with its Correspondent Node in order to avoid
tunneling with its Home Agent, the "optimized" route is no longer
optimized when the mobile host is attached to a mobile network. This
is because the route between the mobile host and its Correspondent
Node is subjected to the sub-optimality introduced by the MRHA
tunnel. Interested readers may refer to <a href="#appendix-A">Appendix A</a> for examples of
how the routes will appear with nesting of Mobile IPv6 hosts in
mobile networks.
The readers should also note that the same sub-optimality would apply
when the mobile host is outside the mobile network and its
Correspondent Node is in the mobile network.
<span class="grey">Ng, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>. Security Policy Prohibiting Traffic from Visiting Nodes</span>
NEMO Basic Support requires all traffic from visitors to be tunneled
to the Mobile Router's Home Agent. This might represent a breach in
the security of the Home Network (some specific attacks against the
Mobile Router's binding by rogue visitors have been documented in
[<a href="#ref-8" title=""Threats for Basic Network Mobility Support (NEMO threats)"">8</a>][9]). Administrators might thus fear that malicious packets will
be routed into the Home Network via the bi-directional tunnel. As a
consequence, it can be expected that in many deployment scenarios,
policies will be put in place to prevent unauthorized Visiting Mobile
Nodes from attaching to the Mobile Router.
However, there are deployment scenarios where allowing unauthorized
Visiting Mobile Nodes is actually desirable. For instance, when
Mobile Routers attach to other Mobile Routers and form a nested NEMO,
they depend on each other to reach the Internet. When Mobile Routers
have no prior knowledge of one another (no security association,
Authentication, Authorization, and Accounting (AAA), Public-Key
Infrastructure (PKI), etc.), it could still be acceptable to forward
packets, provided that the packets are not tunneled back to the Home
Networks.
A Route Optimization mechanism that allows traffic from Mobile
Network Nodes to bypass the bi-directional tunnel between a Mobile
Router and its Home Agent would be a necessary first step towards a
Tit for Tat model, where MRs would benefit from a reciprocal
altruism, based on anonymity and innocuousness, to extend the
Internet infrastructure dynamically.
<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>. Instability of Communications within a Nested Mobile Network</span>
Within a nested mobile network, two Mobile Network Nodes may
communicate with each other. Let us consider the previous example
illustrated in Figure 1 where MNN and CN2 are sharing a communication
session. With NEMO Basic Support, a packet sent from MNN to CN2 will
need to be forwarded to the Home Agent of each Mobile Router before
reaching CN2, whereas, a packet following the direct path between
them need not even leave the mobile network. Readers are referred to
<a href="#appendix-A.3">Appendix A.3</a> for detailed illustration of the resulting routing
paths.
Apart from the consequences of increased packet delay and packet
size, which are discussed in previous sub-sections, there are two
additional effects that are undesirable:
o when the nested mobile network is disconnected from the Internet
(e.g., MR1 loses its egress connectivity), MNN and CN2 can no
<span class="grey">Ng, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
longer communicate with each other, even though the direct path
from MNN to CN2 is unaffected;
o the egress link(s) of the root Mobile Router (i.e., MR1) becomes a
bottleneck for all the traffic that is coming in and out of the
nested mobile network.
A Route Optimization mechanism could allow traffic between two Mobile
Network Nodes nested within the same mobile network to follow a
direct path between them, without being routed out of the mobile
network. This may also off-load the processing burden of the
upstream Mobile Routers when the direct path between the two Mobile
Network Nodes does not traverse these Mobile Routers.
<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>. Stalemate with a Home Agent Nested in a Mobile Network</span>
Several configurations for the Home Network are described in [<a href="#ref-10" title=""Network Mobility Home Network Models"">10</a>].
In particular, there is a mobile home scenario where a (parent)
Mobile Router is also a Home Agent for its mobile network. In other
words, the mobile network is itself an aggregation of Mobile Network
Prefixes assigned to (children) Mobile Routers.
A stalemate situation exists in the case where the parent Mobile
Router visits one of its children. The child Mobile Router cannot
find its Home Agent in the Internet and thus cannot establish its
MRHA tunnel and forward the visitor's traffic. The traffic from the
parent is thus blocked from reaching the Internet, and it will never
bind to its own (grandparent) Home Agent. <a href="#appendix-B">Appendix B</a> gives a
detailed illustration of how such a situation can occur.
Then again, a Route Optimization mechanism that bypasses the nested
tunnel might enable the parent traffic to reach the Internet and let
it bind. At that point, the child Mobile Router would be able to
reach its parent and bind in turn. Additional nested Route
Optimization solutions might also enable the child to locate its Home
Agent in the nested structure and bind regardless of whether or not
the Internet is reachable.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Conclusion</span>
With current NEMO Basic Support, all communications to and from
Mobile Network Nodes must go through the MRHA tunnel when the mobile
network is away. This results in various inefficiencies associated
with packet delivery. This document investigates such inefficiencies
and provides the motivation behind Route Optimization for NEMO.
<span class="grey">Ng, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
We have described the sub-optimal effects of pinball routes with NEMO
Basic Support, how they may cause a bottleneck to be formed in the
Home Network, and how they get amplified with nesting of mobile
networks. These effects will also be seen even when Mobile IPv6
Route Optimization is used over NEMO Basic Support. In addition,
other issues concerning the nesting of mobile networks that might
provide additional motivation for a NEMO Route Optimization mechanism
were also explored, such as the prohibition of forwarding traffic
from a Visiting Mobile Node through an MRHA tunnel due to security
concerns, the impact of the MRHA tunnel on communications between two
Mobile Network Nodes on different links of the same mobile network,
and the possibility of a stalemate situation when Home Agents are
nested within a mobile network.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
This document highlights some limitations of NEMO Basic Support. In
particular, some security concerns could prevent interesting
applications of the protocol, as detailed in <a href="#section-2.5">Section 2.5</a>.
Route Optimization for <a href="./rfc3963">RFC 3963</a> [<a href="#ref-1" title=""Network Mobility (NEMO) Basic Support Protocol"">1</a>] might introduce new threats, just
as it might alleviate existing ones. This aspect will certainly be a
key criterion in the evaluation of the proposed solutions.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Acknowledgments</span>
The authors wish to thank the co-authors of previous versions from
which this document is derived: Marco Molteni, Paik Eun-Kyoung,
Hiroyuki Ohnishi, Thierry Ernst, Felix Wu, and Souhwan Jung. Early
work by Masafumi Watari on the extracted appendix was written while
still at Keio University. In addition, sincere appreciation is also
extended to Jari Arkko, Carlos Bernardos, Greg Daley, T.J. Kniveton,
Henrik Levkowetz, Erik Nordmark, Alexandru Petrescu, Hesham Soliman,
Ryuji Wakikawa, and Patrick Wetterwald for their various
contributions.
<span class="grey">Ng, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative Reference</span>
[<a id="ref-1">1</a>] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", <a href="./rfc3963">RFC 3963</a>,
January 2005.
[<a id="ref-2">2</a>] Manner, J. and M. Kojo, "Mobility Related Terminology",
<a href="./rfc3753">RFC 3753</a>, June 2004.
[<a id="ref-3">3</a>] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
<a href="./rfc4885">RFC 4885</a>, July 2007.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative Reference</span>
[<a id="ref-4">4</a>] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", <a href="./rfc3775">RFC 3775</a>, June 2004.
[<a id="ref-5">5</a>] Ernst, T., "Network Mobility Support Goals and Requirements",
<a href="./rfc4886">RFC 4886</a>, July 2007.
[<a id="ref-6">6</a>] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications",
<a href="./rfc1889">RFC 1889</a>, January 1996.
[<a id="ref-7">7</a>] Deering, S. and B. Zill, "Redundant Address Deletion when
Encapsulating IPv6 in IPv6", Work in Progress, November 2001.
[<a id="ref-8">8</a>] Petrescu, A., Olivereau, A., Janneteau, C., and H-Y. Lach,
"Threats for Basic Network Mobility Support (NEMO threats)",
Work in Progress, January 2004.
[<a id="ref-9">9</a>] Jung, S., Zhao, F., Wu, S., Kim, H-G., and S-W. Sohn, "Threat
Analysis on NEMO Basic Operations", Work in Progress,
July 2004.
[<a id="ref-10">10</a>] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network
Mobility Home Network Models", RFC <a href="./rfc4887">RFC4887</a>, July 2007.
[<a id="ref-11">11</a>] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.
<span class="grey">Ng, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Various Configurations Involving Nested Mobile Networks</span>
In the following sections, we try to describe different communication
models that involve a nested mobile network and to clarify the issues
for each case. We illustrate the path followed by packets if we
assume nodes only use Mobile IPv6 and NEMO Basic Support mechanisms.
Different cases are considered where a Correspondent Node is located
in the fixed infrastructure, in a distinct nested mobile network as
the Mobile Network Node, or in the same nested mobile network as the
Mobile Network Node. Additionally, cases where Correspondent Nodes
and Mobile Network Nodes are either standard IPv6 nodes or Mobile
IPv6 nodes are considered. As defined in [<a href="#ref-3" title=""Network Mobility Support Terminology"">3</a>], standard IPv6 nodes
are nodes with no mobility functions whatsoever, i.e., they are not
Mobile IPv6 or NEMO enabled. This means that they cannot move around
keeping open connections and that they cannot process Binding Updates
sent by peers.
<span class="h3"><a class="selflink" id="appendix-A.1" href="#appendix-A.1">A.1</a>. CN Located in the Fixed Infrastructure</span>
The most typical configuration is the case where a Mobile Network
Node communicates with a Correspondent Node attached in the fixed
infrastructure. Figure 3 below shows an example of such topology.
+--------+ +--------+ +--------+
| MR1_HA | | MR2_HA | | MR3_HA |
+---+----+ +---+----+ +---+----+
| | |
+-------------------------+
| Internet |----+ CN
+-------------------------+
| |
+---+---+ +--+-----+
root-MR | MR1 | | VMN_HA |
+---+---+ +--------+
|
+---+---+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
----+----
MNN
Figure 3: CN Located at the Infrastructure
<span class="grey">Ng, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h4"><a class="selflink" id="appendix-A.1.1" href="#appendix-A.1.1">A.1.1</a>. Case A: LFN and Standard IPv6 CN</span>
The simplest case is where both MNN and CN are fixed nodes with no
mobility functions. That is, MNN is a Local Fixed Node, and CN is a
standard IPv6 node. Packets are encapsulated between each Mobile
Router and its respective Home Agent (HA). As shown in Figure 4, in
such a case, the path between the two nodes would go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
LFN IPv6 Node
The digits represent the number of IPv6 headers.
Figure 4: MNN and CN Are Standard IPv6 Nodes
<span class="h4"><a class="selflink" id="appendix-A.1.2" href="#appendix-A.1.2">A.1.2</a>. Case B: VMN and MIPv6 CN</span>
In this second case, both end nodes are Mobile IPv6-enabled mobile
nodes, that is, MNN is a Visiting Mobile Node. Mobile IPv6 Route
Optimization may thus be initiated between the two and packets would
not go through the Home Agent of the Visiting Mobile Node or the Home
Agent of the Correspondent Node (not shown in the figure). However,
packets will still be tunneled between each Mobile Router and its
respective Home Agent, in both directions. As shown in Figure 5, the
path between MNN and CN would go through:
1 2 3 4 3 2 1
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA --- CN
VMN MIPv6
Figure 5: MNN and CN Are MIPv6 Mobile Nodes
<span class="h4"><a class="selflink" id="appendix-A.1.3" href="#appendix-A.1.3">A.1.3</a>. Case C: VMN and Standard IPv6 CN</span>
When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Node or as a Correspondent Node, Mobile IPv6 Route
Optimization cannot be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. Therefore,
MNN would establish a bi-directional tunnel with its HA, which causes
the flow to go out the nested NEMO. Packets between MNN and CN would
thus go through MNN's own Home Agent (VMN_HA). The path would
therefore be as shown in Figure 6:
<span class="grey">Ng, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
2 3 4 5 4
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA
VMN |
| 3
1 2 |
CN --- VMN_HA --- MR3_HA
IPv6 Node
Figure 6: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
Providing Route Optimization involving a Mobile IPv6 node may require
optimization among the Mobile Routers and the Mobile IPv6 node.
<span class="h3"><a class="selflink" id="appendix-A.2" href="#appendix-A.2">A.2</a>. CN Located in Distinct Nested NEMOs</span>
The Correspondent Node may be located in another nested mobile
network, different from the one MNN is attached to, as shown in
Figure 7. We define such configuration as "distinct nested mobile
networks".
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
| |
+---+---+ +---+---+
root-MR | MR1 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR2 | | MR5 |
+---+---+ +---+---+
| |
+---+---+ ----+----
sub-MR | MR3 | CN
+---+---+
|
----+----
MNN
Figure 7: MNN and CN Located in Distinct Nested NEMOs
<span class="grey">Ng, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h4"><a class="selflink" id="appendix-A.2.1" href="#appendix-A.2.1">A.2.1</a>. Case D: LFN and Standard IPv6 CN</span>
Similar to Case A, we start off with the case where both end nodes do
not have any mobility functions. Packets are encapsulated at every
Mobile Router on the way out of the nested mobile network,
decapsulated by the Home Agents, and then encapsulated again on their
way down the nested mobile network.
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
IPv6 Node
Figure 8: MNN and CN Are Standard IPv6 Nodes
<span class="h4"><a class="selflink" id="appendix-A.2.2" href="#appendix-A.2.2">A.2.2</a>. Case E: VMN and MIPv6 CN</span>
Similar to Case B, when both end nodes are Mobile IPv6 nodes, the two
nodes may initiate Mobile IPv6 Route Optimization. Again, packets
will not go through the Home Agent of the MNN or the Home Agent of
the Mobile IPv6 Correspondent Node (not shown in the figure).
However, packets will still be tunneled for each Mobile Router to its
Home Agent and vice versa. Therefore, the path between MNN and CN
would go through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 1
1 2 3 2 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 9: MNN and CN Are MIPv6 Mobile Nodes
<span class="h4"><a class="selflink" id="appendix-A.2.3" href="#appendix-A.2.3">A.2.3</a>. Case F: VMN and Standard IPv6 CN</span>
Similar to Case C, when the communication involves a Mobile IPv6 node
either as a Visiting Mobile Node or as a Correspondent Node, MIPv6
Route Optimization cannot be performed because the standard IPv6
Correspondent Node cannot process Mobile IPv6 signaling. MNN would
<span class="grey">Ng, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
therefore establish a bi-directional tunnel with its Home Agent.
Packets between MNN and CN would thus go through MNN's own Home Agent
as shown in Figure 10:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
1 2 3 2 1 |
CN --- MR5 --- MR4 --- MR4_HA --- MR5_HA --- VMN_HA
IPv6 Node
Figure 10: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
<span class="h3"><a class="selflink" id="appendix-A.3" href="#appendix-A.3">A.3</a>. MNN and CN Located in the Same Nested NEMO</span>
Figure 11 below shows the case where the two communicating nodes are
connected behind different Mobile Routers that are connected in the
same nested mobile network, and thus behind the same root Mobile
Router. Route Optimization can avoid packets being tunneled outside
the nested mobile network.
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+-------+
| |
+-------+ +-------+
sub-MR | MR2 | | MR4 |
+---+---+ +---+---+
| |
+---+---+ +---+---+
sub-MR | MR3 | | MR5 |
+---+---+ +---+---+
| |
----+---- ----+----
MNN CN
<span class="grey">Ng, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
Figure 11: MNN and CN Located in the Same Nested NEMO
<span class="h4"><a class="selflink" id="appendix-A.3.1" href="#appendix-A.3.1">A.3.1</a>. Case G: LFN and Standard IPv6 CN</span>
Again, we start off with the case where both end nodes do not have
any mobility functions. Packets are encapsulated at every Mobile
Router on the way out of the nested mobile network via the root
Mobile Router, decapsulated and encapsulated by the Home Agents, and
then make their way back to the nested mobile network through the
same root Mobile Router. Therefore, the path between MNN and CN
would go through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 12: MNN and CN Are Standard IPv6 nodes
<span class="h4"><a class="selflink" id="appendix-A.3.2" href="#appendix-A.3.2">A.3.2</a>. Case H: VMN and MIPv6 CN</span>
Similar to Case B and Case E, when both end nodes are Mobile IPv6
nodes, the two nodes may initiate Mobile IPv6 Route Optimization,
which will avoid the packets going through the Home Agent of MNN or
the Home Agent of the Mobile IPv6 CN (not shown in the figure).
However, packets will still be tunneled between each Mobile Router
and its respective Home Agent in both directions. Therefore, the
path would be the same as with Case G and go through:
1 2 3 4 3 2
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
LFN |
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
MIPv6 Node
Figure 13: MNN and CN Are MIPv6 Mobile Nodes
<span class="grey">Ng, et al. Informational [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h4"><a class="selflink" id="appendix-A.3.3" href="#appendix-A.3.3">A.3.3</a>. Case I: VMN and Standard IPv6 CN</span>
As for Case C and Case F, when the communication involves a Mobile
IPv6 node either as a Visiting Mobile Node or as a Correspondent
Node, Mobile IPv6 Route Optimization cannot be performed. Therefore,
MNN will establish a bi-directional tunnel with its Home Agent.
Packets between MNN and CN would thus go through MNN's own Home
Agent. The path would therefore be as shown in Figure 14:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR4_HA --- MR5_HA
IPv6 Node
Figure 14: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
<span class="h3"><a class="selflink" id="appendix-A.4" href="#appendix-A.4">A.4</a>. CN Located Behind the Same Nested MR</span>
Figure 15 below shows the case where the two communicating nodes are
connected behind the same nested Mobile Router. The optimization is
required when the communication involves MIPv6-enabled nodes.
<span class="grey">Ng, et al. Informational [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
+--------+ +--------+ +--------+ +--------+
| MR2_HA | | MR3_HA | | MR4_HA | | MR5_HA |
+------+-+ +---+----+ +---+----+ +-+------+
\ | | /
+--------+ +-------------------------+ +--------+
| MR1_HA |----| Internet |----| VMN_HA |
+--------+ +-------------------------+ +--------+
|
+---+---+
root-MR | MR1 |
+---+---+
|
+-------+
sub-MR | MR2 |
+---+---+
|
+---+---+
sub-MR | MR3 |
+---+---+
|
-+--+--+-
MNN CN
Figure 15: MNN and CN Located Behind the Same Nested MR
<span class="h4"><a class="selflink" id="appendix-A.4.1" href="#appendix-A.4.1">A.4.1</a>. Case J: LFN and Standard IPv6 CN</span>
If both end nodes are Local Fixed Nodes, no special function is
necessary for optimization of their communications. The path between
the two nodes would go through:
1
MNN --- CN
LFN IPv6 Node
Figure 16: MNN and CN Are Standard IPv6 Nodes
<span class="h4"><a class="selflink" id="appendix-A.4.2" href="#appendix-A.4.2">A.4.2</a>. Case K: VMN and MIPv6 CN</span>
Similar to Case H, when both end nodes are Mobile IPv6 nodes, the two
nodes may initiate Mobile IPv6 Route Optimization. Although few
packets would go out the nested mobile network for the Return
Routability initialization, however, unlike Case B and Case E,
packets will not get tunneled outside the nested mobile network.
Therefore, packets between MNN and CN would eventually go through:
<span class="grey">Ng, et al. Informational [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
1
MNN --- CN
VMN MIPv6 Node
Figure 17: MNN and CN are MIPv6 Mobile Nodes
If the root Mobile Router is disconnected while the nodes exchange
keys for the Return Routability procedure, they may not communicate
even though they are connected on the same link.
<span class="h4"><a class="selflink" id="appendix-A.4.3" href="#appendix-A.4.3">A.4.3</a>. Case L: VMN and Standard IPv6 CN</span>
When the communication involves a Mobile IPv6 node either as a
Visiting Mobile Network Node or as a Correspondent Node, Mobile IPv6
Route Optimization cannot be performed. Therefore, even though the
two nodes are on the same link, MNN will establish a bi-directional
tunnel with its Home Agent, which causes the flow to go out the
nested mobile network. The path between MNN and CN would require
another Home Agent (VMN_HA) to go through for this Mobile IPv6 node:
2 3 4 5 4 3
MNN --- MR3 --- MR2 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
VMN |
| 2
|
VMN_HA
|
| 1
1 2 3 4 3 2 |
CN --- MR5 --- MR4 --- MR1 --- MR1_HA --- MR2_HA --- MR3_HA
IPv6 Node
Figure 18: MNN is an MIPv6 Mobile Node and CN is a Standard IPv6 Node
However, MNN may also decide to use its Care-of Address (CoA) as the
source address of the packets, thus avoiding the tunneling with the
MNN's Home Agent. This is particularly useful for a short-term
communications that may easily be retried if it fails. Default
Address Selection [<a href="#ref-11" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">11</a>] provides some mechanisms for controlling the
choice of the source address.
<span class="grey">Ng, et al. Informational [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Example of How a Stalemate Situation Can Occur</span>
<a href="#section-2.7">Section 2.7</a> describes the occurrence of a stalemate situation where a
Home Agent of a Mobile Router is nested behind the Mobile Router.
Here, we illustrate a simple example where such a situation can
occur.
Consider a mobility configuration depicted in Figure 19 below. MR1
is served by HA1/BR and MR2 is served by HA2. The 'BR' designation
indicates that HA1 is a border router. Both MR1 and MR2 are at home
in the initial step. HA2 is placed inside the first mobile network,
thus representing a "mobile" Home Agent.
/-----CN
+----------+
home link 1 +--------+ | |
----+-----------------| HA1/BR |---| Internet |
| +--------+ | |
| +----------+
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
-+--------+-- mobile net 1 / home link 2
|
+--+--+ +--+--+
| MR2 | | LFN |
+--+--+ +--+--+
| |
-+--------+- mobile net 2
Figure 19: Initial Deployment
In Figure 19 above, communications between CN and LFN follow a direct
path as long as both MR1 and MR2 are positioned at home. No
encapsulation intervenes.
In the next step, consider that the MR2's mobile network leaves home
and visits a foreign network, under Access Router (AR) like in
Figure 20 below.
<span class="grey">Ng, et al. Informational [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
/-----CN
+----------+
home link 1 +--------+ | |
--+-----------| HA1/BR |---| Internet |
| +--------+ | |
+--+--+ +-----+ +----------+
| MR1 | | HA2 | \
+--+--+ +--+--+ +-----+
| | | AR |
-+--------+- mobile net 1 +--+--+
home link 2 |
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
Figure 20: Mobile Network 2 Leaves Home
Once MR2 acquires a Care-of Address under AR, the tunnel setup
procedure occurs between MR2 and HA2. MR2 sends a Binding Update to
HA2 and HA2 replies with a Binding Acknowledgement to MR2. The bi-
directional tunnel has MR2 and HA2 as tunnel endpoints. After the
tunnel MR2HA2 has been set up, the path taken by a packet from CN
towards LFN can be summarized as:
CN->BR->MR1->HA2=>MR1=>BR=>AR=>MR2->LFN.
Non-encapsulated packets are marked "->" while encapsulated packets
are marked "=>".
Consider next the attachment of the first mobile network under the
second mobile network, like in Figure 21 below.
After this movement, MR1 acquires a Care-of Address valid in the
second mobile network. Subsequently, it sends a Binding Update (BU)
message addressed to HA1. This Binding Update is encapsulated by MR2
and sent towards HA2, which is expected to be placed in mobile net 1
and expected to be at home. Once HA1/BR receives this encapsulated
BU, it tries to deliver to MR1. Since MR1 is not at home, and a
tunnel has not yet been set up between MR1 and HA1, HA1 is not able
to route this packet and drops it. Thus, the tunnel establishment
procedure between MR1 and HA1 is not possible, because the tunnel
between MR2 and HA2 had been previously torn down (when the mobile
net 1 moved from home). The communications between CN and LFN stops,
even though both mobile networks are connected to the Internet.
<span class="grey">Ng, et al. Informational [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
/-----CN
+----------+
+--------+ | |
| HA1/BR |---| Internet |
+--------+ | |
+----------+
\
+-----+
| AR |
+--+--+
|
+--+--+ +-----+
| MR2 | | LFN |
+--+--+ +--+--+
| |
mobile net 2 -+--------+-
|
+--+--+ +-----+
| MR1 | | HA2 |
+--+--+ +--+--+
| |
mobile net 1 -+--------+-
Figure 21: Stalemate Situation Occurs
If both tunnels between MR1 and HA1, and between MR2 and HA2, were up
simultaneously, they would have "crossed over" each other. If the
tunnels MR1-HA1 and MR2-HA2 were drawn in Figure 21, it could be
noticed that the path of the tunnel MR1-HA1 includes only one
endpoint of the tunnel MR2-HA2 (the MR2 endpoint). Two MR-HA tunnels
are crossing over each other if the IP path between two endpoints of
one tunnel includes one and only one endpoint of the other tunnel
(assuming that both tunnels are up). When both endpoints of one
tunnel are included in the path of the other tunnel, then tunnels are
simply encapsulating each other.
<span class="grey">Ng, et al. Informational [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
Authors' Addresses
Chan-Wah Ng
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate, Singapore 534415
SG
Phone: +65 65505420
EMail: chanwah.ng@sg.panasonic.com
Pascal Thubert
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3, Biot - Sophia Antipolis 06410
FRANCE
EMail: pthubert@cisco.com
Masafumi Watari
KDDI R&D Laboratories Inc.
2-1-15 Ohara
Fujimino, Saitama 356-8502
JAPAN
EMail: watari@kddilabs.jp
Fan Zhao
UC Davis
One Shields Avenue
Davis, CA 95616
US
Phone: +1 530 752 3128
EMail: fanzhao@ucdavis.edu
<span class="grey">Ng, et al. Informational [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc4888">RFC 4888</a> NEMO RO Problem Statement July 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Ng, et al. Informational [Page 26]
</pre>
|
