File: rfc3024.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1683 lines) | stat: -rw-r--r-- 63,929 bytes parent folder | download | duplicates (5)
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
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683






Network Working Group                              G. Montenegro, Editor
Request for Comments: 3024                        Sun Microsystems, Inc.
Obsoletes: 2344                                             January 2001
Category: Standards Track


                Reverse Tunneling for Mobile IP, revised

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   Mobile Internet Protocol (IP) uses tunneling from the home agent to
   the mobile node's care-of address, but rarely in the reverse
   direction.  Usually, a mobile node sends its packets through a router
   on the foreign network, and assumes that routing is independent of
   source address.  When this assumption is not true, it is convenient
   to establish a topologically correct reverse tunnel from the care-of
   address to the home agent.

   This document proposes backwards-compatible extensions to Mobile IP
   to support topologically correct reverse tunnels.  This document does
   not attempt to solve the problems posed by firewalls located between
   the home agent and the mobile node's care-of address.

   This document obsoletes RFC 2344.















Montenegro                  Standards Track                     [Page 1]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


Table of Contents

   1. Introduction ...................................................  3
   1.1. Terminology ..................................................  4
   1.2. Assumptions ..................................................  4
   1.3. Justification ................................................  5
   2. Overview .......................................................  5
   3. New Packet Formats .............................................  6
   3.1. Mobility Agent Advertisement Extension .......................  6
   3.2. Registration Request .........................................  6
   3.3. Encapsulating Delivery Style Extension .......................  7
   3.4. New Registration Reply Codes .................................  8
   4. Changes in Protocol Behavior ...................................  9
   4.1. Mobile Node Considerations ...................................  9
   4.1.1. Sending Registration Requests to the Foreign Agent .........  9
   4.1.2. Receiving Registration Replies from the Foreign Agent ...... 10
   4.2. Foreign Agent Considerations ................................. 10
   4.2.1. Receiving Registration Requests from the Mobile Node ....... 11
   4.2.2. Relaying Registration Requests to the Home Agent ........... 11
   4.3. Home Agent Considerations .................................... 11
   4.3.1. Receiving Registration Requests from the Foreign Agent ..... 12
   4.3.2. Sending Registration Replies to the Foreign Agent .......... 12
   5. Mobile Node to Foreign Agent Delivery Styles ................... 13
   5.1. Direct Delivery Style ........................................ 13
   5.1.1. Packet Processing .......................................... 13
   5.1.2. Packet Header Format and Fields ............................ 13
   5.2. Encapsulating Delivery Style ................................. 14
   5.2.1 Packet Processing ........................................... 14
   5.2.2. Packet Header Format and Fields ............................ 15
   5.3. Support for Broadcast and Multicast Datagrams ................ 16
   5.4. Selective Reverse Tunneling .................................. 16
   6. Security Considerations ........................................ 17
   6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks ....... 17
   6.2. Ingress Filtering ............................................ 18
   6.3. Reverse Tunneling for Disparate Address Spaces ............... 18
   7. IANA Considerations ............................................ 18
   8. Acknowledgements ............................................... 18
   References ........................................................ 19
   Editor and Chair Addresses ........................................ 20
   Appendix A: Disparate Address Space Support ....................... 21
      A.1. Scope of the Reverse Tunneling Solution ................... 21
      A.2. Terminating Forward Tunnels at the Foreign Agent .......... 24
      A.3. Initiating Reverse Tunnels at the Foreign Agent ........... 26
      A.4. Limited Private Address Scenario .......................... 26
   Appendix B: Changes from RFC2344 .................................. 29
   Full Copyright Statement .......................................... 30





Montenegro                  Standards Track                     [Page 2]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


1. Introduction

   Section 1.3 of the Mobile IP specification [1] lists the following
   assumption:

      It is assumed that IP unicast datagrams are routed based on the
      destination address in the datagram header (i.e., not by source
      address).

   Because of security concerns (for example, IP spoofing attacks), and
   in accordance with RFC 2267 [8] and CERT [3] advisories to this
   effect, routers that break this assumption are increasingly more
   common.

   In the presence of such routers, the source and destination IP
   address in a packet must be topologically correct.  The forward
   tunnel complies with this, as its endpoints (home agent address and
   care-of address) are properly assigned addresses for their respective
   locations.  On the other hand, the source IP address of a packet
   transmitted by the mobile node does not correspond to the network
   prefix from where it emanates.

   This document discusses topologically correct reverse tunnels.

   Mobile IP does dictate the use of reverse tunnels in the context of
   multicast datagram routing and mobile routers.  However, the source
   IP address is set to the mobile node's home address, so these tunnels
   are not topologically correct.

   Notice that there are several uses for reverse tunnels regardless of
   their topological correctness:

      -  Mobile routers: reverse tunnels obviate the need for recursive
         tunneling [1].

      -  Multicast: reverse tunnels enable a mobile node away from home
         to (1) join multicast groups in its home network, and (2)
         transmit multicast packets such that they emanate from its home
         network [1].

      -  The TTL of packets sent by the mobile node (for example, when
         sending packets to other hosts in its home network) may be so
         low that they might expire before reaching their destination.
         A reverse tunnel solves the problem as it represents a TTL
         decrement of one [5].






Montenegro                  Standards Track                     [Page 3]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


1.1. Terminology

   The discussion below uses terms defined in the Mobile IP
   specification.  Additionally, it uses the following terms:

      Forward Tunnel

         A tunnel that shuttles packets towards the mobile node.  It
         starts at the home agent, and ends at the mobile node's care-of
         address.

      Reverse Tunnel

         A tunnel that starts at the mobile node's care-of address and
         terminates at the home agent.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [9].

1.2. Assumptions

   Mobility is constrained to a common IP address space (that is, the
   routing fabric between, say, the mobile node and the home agent is
   not partitioned into a "private" and a "public" network).

   This document does not attempt to solve the firewall traversal
   problem.  Rather, it assumes one of the following is true:

      -  There are no intervening firewalls along the path of the
         tunneled packets.

      -  Any intervening firewalls share the security association
         necessary to process any authentication [6] or encryption [7]
         headers which may have been added to the tunneled packets.

   The reverse tunnels considered here are symmetric, that is, they use
   the same configuration (encapsulation method, IP address endpoints)
   as the forward tunnel.  IP in IP encapsulation [2] is assumed unless
   stated otherwise.

   Route optimization [4] introduces forward tunnels initiated at a
   correspondent host.  Since a mobile node may not know if the
   correspondent host can decapsulate packets, reverse tunnels in that
   context are not discussed here.






Montenegro                  Standards Track                     [Page 4]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


1.3. Justification

   Why not let the mobile node itself initiate the tunnel to the home
   agent?  This is indeed what it should do if it is already operating
   with a topologically correct co-located care-of address.

   However, one of the primary objectives of the Mobile IP specification
   is not to require this mode of operation.

   The mechanisms outlined in this document are primarily intended for
   use by mobile nodes that rely on the foreign agent for forward tunnel
   support.  It is desirable to continue supporting these mobile nodes,
   even in the presence of filtering routers.

2. Overview

   A mobile node arrives at a foreign network, listens for agent
   advertisements and selects a foreign agent that supports reverse
   tunnels.  It requests this service when it registers through the
   selected foreign agent.  At this time, and depending on how the
   mobile node wishes to deliver packets to the foreign agent, it also
   requests either the Direct or the Encapsulating Delivery Style
   (section 5).

   In the Direct Delivery Style, the mobile node designates the foreign
   agent as its default router and proceeds to send packets directly to
   the foreign agent, that is, without encapsulation.  The foreign agent
   intercepts them, and tunnels them to the home agent.

   In the Encapsulating Delivery Style, the mobile node encapsulates all
   its outgoing packets to the foreign agent.  The foreign agent
   decapsulates and re-tunnels them to the home agent, using the foreign
   agent's care-of address as the entry-point of this new tunnel.


















Montenegro                  Standards Track                     [Page 5]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


3. New Packet Formats

3.1. Mobility Agent Advertisement Extension

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Sequence Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Lifetime            |R|B|H|F|M|G|V|T|  reserved     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |

   The only change to the Mobility Agent Advertisement Extension [1] is
   the additional 'T' bit:

      T        Agent offers reverse tunneling service.

   A foreign agent that sets the 'T' bit MUST support the Direct
   Delivery Style. Encapsulating Delivery Style SHOULD be supported as
   well (section 5).

   Using this information, a mobile node is able to choose a foreign
   agent that supports reverse tunnels.  Notice that if a mobile node
   does not understand this bit, it simply ignores it as per [1].

3.2. Registration Request

   Reverse tunneling support is added directly into the Registration
   Request by using one of the "rsvd" bits.  If a foreign or home agent
   that does not support reverse tunnels receives a request with the 'T'
   bit set, the Registration Request fails.  This results in a
   registration denial (failure codes are specified in section 3.4).

   Home agents SHOULD NOT object to providing reverse tunnel support,
   because they "SHOULD be able to decapsulate and further deliver
   packets addressed to themselves, sent by a mobile node" [1].  In the
   case of topologically correct reverse tunnels, the packets are not
   sent by the mobile node as distinguished by its home address.
   Rather, the outermost (encapsulating) IP source address on such
   datagrams is the care-of address of the mobile node.

   In Registration Requests sent by a mobile node, the Time to Live
   field in the IP header MUST be set to 255.  This limits a denial of
   service attack in which malicious hosts send false Registration
   Requests (see Section 6).




Montenegro                  Standards Track                     [Page 6]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |S|B|D|M|G|V|T|-|          Lifetime             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Home Address                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Home Agent                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Care-of Address                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Identification                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extensions ...
   +-+-+-+-+-+-+-+-

   The only change to the Registration Request packet is the additional
   'T' bit:

   T        If the 'T' bit is set, the mobile node asks its home
            agent to accept a reverse tunnel from the care-of
            address.  Mobile nodes using a foreign agent care-of
            address ask the foreign agent to reverse-tunnel its
            packets.

3.3. Encapsulating Delivery Style Extension

   The Encapsulating Delivery Style Extension MAY be included by the
   mobile node in registration requests to further specify reverse
   tunneling behavior.  It is expected to be used only by the foreign
   agent.  Accordingly, the foreign agent MUST consume this extension
   (that is, it must not relay it to the home agent or include it in
   replies to the mobile node).  As per Section 3.6.1.3 of [1], the
   mobile node MUST include the Encapsulating Delivery Style Extension
   after the Mobile-Home Authentication Extension, and before the
   Mobile-Foreign Authentication Extension, if present.

   The Encapsulating Delivery Style Extension MUST NOT be included if
   the 'T' bit is not set in the Registration Request.

   If this extension is absent, Direct Delivery is assumed.
   Encapsulation is done according to what was negotiated for the
   forward tunnel (that is, IP in IP is assumed unless specified
   otherwise).  For more details on the delivery styles, please refer to
   section 5.





Montenegro                  Standards Track                     [Page 7]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Foreign agents SHOULD support the Encapsulating Delivery Style
   Extension.

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         130

      Length

         0

3.4. New Registration Reply Codes

   Foreign and home agent registration replies MUST convey if the
   reverse tunnel request failed.  These new reply codes are defined:

      Service denied by the foreign agent:

      74 requested reverse tunnel unavailable
      75 reverse tunnel is mandatory and 'T' bit not set
      76 mobile node too distant
      79 delivery style not supported

      NOTE: Code 79 has not yet been assigned by IANA.

   and

      Service denied by the home agent:

      137 requested reverse tunnel unavailable
      138 reverse tunnel is mandatory and 'T' bit not set
      139 requested encapsulation unavailable

   In response to a Registration Request with the 'T' bit set, mobile
   nodes may receive (and MUST accept) code 70 (poorly formed request)
   from foreign agents and code 134 (poorly formed request) from home
   agents.  However, foreign and home agents that support reverse
   tunneling MUST use codes 74 and 137, respectively.

   In addition to setting the 'T' bit, the mobile node also MAY request
   the Encapsulating Delivery Style by including the corresponding
   extension.  If a foreign agent does not implement the Encapsulating



Montenegro                  Standards Track                     [Page 8]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Delivery Style, it MUST respond to the mobile node with code 79
   (delivery style not supported).  This also applies if the foreign
   agent does not support a requested delivery style that may be defined
   in the future.

   Absence of the 'T' bit in a Registration Request MAY elicit denials
   with codes 75 and 138 at the foreign agent and the home agent,
   respectively.

   Forward and reverse tunnels are symmetric, that is, both are able to
   use the same tunneling options negotiated at registration.  This
   implies that the home agent MUST deny registrations if an unsupported
   form of tunneling is requested (code 139).  Notice that Mobile IP [1]
   already defines the analogous failure code 72 for use by the foreign
   agent.

4. Changes in Protocol Behavior

   Unless otherwise specified, behavior specified by Mobile IP [1] is
   assumed.  In particular, if any two entities share a mobility
   security association, they MUST use the appropriate Authentication
   Extension (Mobile-Foreign, Foreign-Home or Mobile-Home Authentication
   Extension) when exchanging registration protocol datagrams.  An
   admissible authentication extension (for example the Mobile-Home
   Authentication Extension) MUST always be present to authenticate
   registration messages between a mobile node and its home agent.

   Reverse tunneling imposes additional protocol processing requirements
   on mobile entities.  Differences in protocol behavior with respect to
   Mobile IP [1] are specified in the subsequent sections.

4.1. Mobile Node Considerations

   This section describes how the mobile node handles registrations that
   request a reverse tunnel.

4.1.1. Sending Registration Requests to the Foreign Agent

   In addition to the considerations in [1], a mobile node sets the 'T'
   bit in its Registration Request to petition a reverse tunnel.

   The mobile node MUST set the TTL field of the IP header to 255.  This
   is meant to limit the reverse tunnel hijacking attack (Section 6).

   The mobile node MAY optionally include an Encapsulating Delivery
   Style Extension.





Montenegro                  Standards Track                     [Page 9]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.1.2. Receiving Registration Replies from the Foreign Agent

   Possible valid responses are:

      -  A registration denial issued by either the home agent or the
         foreign agent:

         a. The mobile node follows the error checking guidelines in
            [1], and depending on the reply code, MAY try modifying the
            registration request (for example, by eliminating the
            request for alternate forms of encapsulation or delivery
            style), and issuing a new registration.

         b. Depending on the reply code, the mobile node MAY try zeroing
            the 'T' bit, eliminating the Encapsulating Delivery Style
            Extension (if one was present), and issuing a new
            registration.  Notice that after doing so the registration
            may succeed, but due to the lack of a reverse tunnel data
            transfer may not be possible.

      -  The home agent returns a Registration Reply indicating that the
         service will be provided.

   In this last case, the mobile node has succeeded in establishing a
   reverse tunnel between its care-of address and its home agent.  If
   the mobile node is operating with a co-located care-of address, it
   MAY encapsulate outgoing data such that the destination address of
   the outer header is the home agent.  This ability to selectively
   reverse-tunnel packets is discussed further in section 5.4.

   If the care-of address belongs to a separate foreign agent, the
   mobile node MUST employ whatever delivery style was requested (Direct
   or Encapsulating) and proceed as specified in section 5.

   A successful registration reply is an assurance that both the foreign
   agent and the home agent support whatever alternate forms of
   encapsulation (other than IP in IP) were requested.  Accordingly, the
   mobile node MAY use them at its discretion.

4.2. Foreign Agent Considerations

   This section describes how the foreign agent handles registrations
   that request a reverse tunnel.








Montenegro                  Standards Track                    [Page 10]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.2.1. Receiving Registration Requests from the Mobile Node

   A foreign agent that receives a Registration Request with the 'T' bit
   set processes the packet as specified in the Mobile IP specification
   [1], and determines whether it can accommodate the forward tunnel
   request.  If it cannot, it returns an appropriate code.  In
   particular, if the foreign agent is unable to support the requested
   form of encapsulation it MUST return code 72.  If it cannot support
   the requested form of delivery style it MUST return code 79 (delivery
   style not supported).

   The foreign agent MAY reject Registration Requests without the 'T'
   bit set by denying them with code 75 (reverse tunnel is mandatory and
   'T' bit not set).

   The foreign agent MUST verify that the TTL field of the IP header is
   set to 255.  Otherwise, it MUST reject the registration with code 76
   (mobile node too distant).  The foreign agent MUST limit the rate at
   which it sends these registration replies to a maximum of one per
   second.

   As a last check, the foreign agent verifies that it can support a
   reverse tunnel with the same configuration.  If it cannot, it MUST
   return a Registration Reply denying the request with code 74
   (requested reverse tunnel unavailable).

4.2.2. Relaying Registration Requests to the Home Agent

   Otherwise, the foreign agent MUST relay the Registration Request to
   the home agent.

   Upon receipt of a Registration Reply that satisfies validity checks,
   the foreign agent MUST update its visitor list, including indication
   that this mobile node has been granted a reverse tunnel and the
   delivery style expected (section 5).

   While this visitor list entry is in effect, the foreign agent MUST
   process incoming traffic according to the delivery style, encapsulate
   it and tunnel it from the care-of address to the home agent's
   address.

4.3. Home Agent Considerations

   This section describes how the home agent handles registrations that
   request a reverse tunnel.






Montenegro                  Standards Track                    [Page 11]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


4.3.1. Receiving Registration Requests from the Foreign Agent

   A home agent that receives a Registration Request with the 'T' bit
   set processes the packet as specified in the Mobile IP specification
   [1] and determines whether it can accommodate the forward tunnel
   request.  If it cannot, it returns an appropriate code.  In
   particular, if the home agent is unable to support the requested form
   of encapsulation it MUST return code 139 (requested encapsulation
   unavailable).

   The home agent MAY reject registration requests without the 'T' bit
   set by denying them with code 138 (reverse tunnel is mandatory and '
   T' bit not set).

   As a last check, the home agent determines whether it can support a
   reverse tunnel with the same configuration as the forward tunnel.  If
   it cannot, it MUST send back a registration denial with code 137
   (requested reverse tunnel unavailable).

   Upon receipt of a Registration Reply that satisfies validity checks,
   the home agent MUST update its mobility bindings list to indicate
   that this mobile node has been granted a reverse tunnel and the type
   of encapsulation expected.

4.3.2. Sending Registration Replies to the Foreign Agent

   In response to a valid Registration Request, a home agent MUST issue
   a Registration Reply to the mobile node.

   After a successful registration, the home agent may receive
   encapsulated packets addressed to itself.  Decapsulating such packets
   and blindly injecting them into the network is a potential security
   weakness (section 6.1).  Accordingly, the home agent MUST implement,
   and, by default, SHOULD enable the following check for encapsulated
   packets addressed to itself:

      The home agent searches for a mobility binding whose care-of
      address is the source of the outer header, and whose mobile node
      address is the source of the inner header.

   If no such binding is found, or if the packet uses an encapsulation
   mechanism that was not negotiated at registration the home agent MUST
   silently discard the packet and SHOULD log the event as a security
   exception.

   Home agents that terminate tunnels unrelated to Mobile IP (for
   example, multicast tunnels) MAY turn off the above check, but this
   practice is discouraged for the aforementioned reasons.



Montenegro                  Standards Track                    [Page 12]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   While the registration is in effect, a home agent MUST process each
   valid reverse tunneled packet (as determined by checks like the
   above) by decapsulating it, recovering the original packet, and then
   forwarding it on behalf of its sender (the mobile node) to the
   destination address (the correspondent host).

5. Mobile Node to Foreign Agent Delivery Styles

   This section specifies how the mobile node sends its data traffic via
   the foreign agent.  In all cases, the mobile node learns the foreign
   agent's link-layer address from the link-layer header in the agent
   advertisement.

5.1. Direct Delivery Style

   This delivery mechanism is very simple to implement at the mobile
   node, and uses small (non-encapsulated) packets on the link between
   the mobile node and the foreign agent (potentially a very slow link).
   However, it only supports reverse-tunneling of unicast packets, and
   does not allow selective reverse tunneling (section 5.4).

5.1.1. Packet Processing

   The mobile node MUST designate the foreign agent as its default
   router.  Not doing so will not guarantee encapsulation of all the
   mobile node's outgoing traffic, and defeats the purpose of the
   reverse tunnel.  The foreign agent MUST:

      -  detect packets sent by the mobile node, and

      -  modify its forwarding function to encapsulate them before
         forwarding.

5.1.2. Packet Header Format and Fields

   This section shows the format of the packet headers used by the
   Direct Delivery style.  The formats shown assume IP in IP
   encapsulation [2].

   Packet format received by the foreign agent (Direct Delivery Style):

      IP fields:
        Source Address = mobile node's home address
        Destination Address = correspondent host's address
      Upper Layer Protocol

   Packet format forwarded by the foreign agent (Direct Delivery Style):




Montenegro                  Standards Track                    [Page 13]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      IP fields (encapsulating header):
        Source Address = foreign agent's care-of address
        Destination Address = home agent's address
        Protocol field: 4 (IP in IP)
      IP fields (original header):
        Source Address = mobile node's home address
        Destination Address = correspondent host's address
      Upper Layer Protocol

   These fields of the encapsulating header MUST be chosen as follows:

      IP Source Address

         Copied from the Care-of Address field within the Registration
         Request.

      IP Destination Address

         Copied from the Home Agent field within the most recent
         successful Registration Reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

5.2. Encapsulating Delivery Style

   This mechanism requires that the mobile node implement encapsulation,
   and explicitly directs packets at the foreign agent by designating it
   as the destination address in a new outermost header.  Mobile nodes
   that wish to send either broadcast or multicast packets MUST use the
   Encapsulating Delivery Style.

5.2.1 Packet Processing

   The foreign agent does not modify its forwarding function.  Rather,
   it receives an encapsulated packet and after verifying that it was
   sent by the mobile node, it:

      -  decapsulates to recover the inner packet,

      -  re-encapsulates, and sends it to the home agent.

   If a foreign agent receives an un-encapsulated packet from a mobile
   node which had explicitly requested the Encapsulated Delivery Style,
   then the foreign agent MUST NOT reverse tunnel such a packet and
   rather MUST forward it using standard, IP routing mechanisms.



Montenegro                  Standards Track                    [Page 14]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


5.2.2. Packet Header Format and Fields

   This section shows the format of the packet headers used by the
   Encapsulating Delivery style.  The formats shown assume IP in IP
   encapsulation [2].

   Packet format received by the foreign agent (Encapsulating Delivery
   Style):

      IP fields (encapsulating header):
        Source Address = mobile node's home address
        Destination Address = foreign agent's address
        Protocol field: 4 (IP in IP)
      IP fields (original header):
        Source Address = mobile node's home address
        Destination Address = correspondent host's address
      Upper Layer Protocol

   The fields of the encapsulating IP header MUST be chosen as follows:

      IP Source Address

         The mobile node's home address.

      IP Destination Address

         The address of the agent as learned from the IP source address
         of the agent's most recent successful registration reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

   Packet format forwarded by the foreign agent (Encapsulating Delivery
   Style):

      IP fields (encapsulating header):
        Source Address = foreign agent's care-of address
        Destination Address = home agent's address
        Protocol field: 4 (IP in IP)
      IP fields (original header):
        Source Address = mobile node's home address
        Destination Address = correspondent host's address
      Upper Layer Protocol

   These fields of the encapsulating IP header MUST be chosen as
   follows:



Montenegro                  Standards Track                    [Page 15]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      IP Source Address

         Copied from the Care-of Address field within the Registration
         Request.

      IP Destination Address

         Copied from the Home Agent field within the most recent
         successful Registration Reply.

      IP Protocol Field

         Default is 4 (IP in IP [2]), but other methods of encapsulation
         MAY be used as negotiated at registration time.

5.3. Support for Broadcast and Multicast Datagrams

   If a mobile node is operating with a co-located care-of address,
   broadcast and multicast datagrams are handled according to Sections
   4.3 and 4.4 of the Mobile IP specification [1].  Mobile nodes using a
   foreign agent care-of address MAY have their broadcast and multicast
   datagrams reverse-tunneled by the foreign agent.  However, any mobile
   nodes doing so MUST use the encapsulating delivery style.

   This delivers the datagram only to the foreign agent.  The latter
   decapsulates it and then processes it as any other packet from the
   mobile node, namely, by reverse tunneling it to the home agent.

5.4. Selective Reverse Tunneling

   Packets destined to local resources (for example, a nearby printer)
   might be unaffected by ingress filtering.  A mobile node with a co-
   located care-of address MAY optimize delivery of these packets by not
   reverse tunneling them.  On the other hand, a mobile node using a
   foreign agent care-of address MAY use this selective reverse
   tunneling capability by requesting the Encapsulating Delivery Style,
   and following these guidelines:

      Packets NOT meant to be reversed tunneled:

         Sent using the Direct Delivery style.  The foreign agent MUST
         process these packets as regular traffic:  they MAY be
         forwarded but MUST NOT be reverse tunneled to the home agent.








Montenegro                  Standards Track                    [Page 16]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      Packets meant to be reverse tunneled:

         Sent using the Encapsulating Delivery style.  The foreign agent
         MUST process these packets as specified in section 5.2: they
         MUST be reverse tunneled to the home agent.

6. Security Considerations

   The extensions outlined in this document are subject to the security
   considerations outlined in the Mobile IP specification [1].
   Essentially, creation of both forward and reverse tunnels involves an
   authentication procedure, which reduces the risk for attack.

6.1. Reverse-tunnel Hijacking and Denial-of-Service Attacks

   Once the tunnel is set up, a malicious node could hijack it to inject
   packets into the network.  Reverse tunnels might exacerbate this
   problem, because upon reaching the tunnel exit point packets are
   forwarded beyond the local network.  This concern is also present in
   the Mobile IP specification, as it already dictates the use of
   reverse tunnels for certain applications.

   Unauthenticated exchanges involving the foreign agent allow a
   malicious node to pose as a valid mobile node and re-direct an
   existing reverse tunnel to another home agent, perhaps another
   malicious node.  The best way to protect against these attacks is by
   employing the Mobile-Foreign and Foreign-Home Authentication
   Extensions defined in [1].

   If the necessary mobility security associations are not available,
   this document introduces a mechanism to reduce the range and
   effectiveness of the attacks.  The mobile node MUST set to 255 the
   TTL value in the IP headers of Registration Requests sent to the
   foreign agent.  This prevents malicious nodes more than one hop away
   from posing as valid mobile nodes.  Additional codes for use in
   registration denials make those attacks that do occur easier to
   track.

   With the goal of further reducing the attacks the Mobile IP Working
   Group considered other mechanisms involving the use of
   unauthenticated state.  However, these introduce the possibilities of
   denial-of-service attacks.  The consensus was that this was too much
   of a trade-off for mechanisms that guarantee no more than weak (non-
   cryptographic) protection against attacks.







Montenegro                  Standards Track                    [Page 17]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


6.2. Ingress Filtering

   There has been some concern regarding the long-term effectiveness of
   reverse-tunneling in the presence of ingress filtering.  The
   conjecture is that network administrators will target reverse-
   tunneled packets (IP in IP encapsulated packets) for filtering.  The
   ingress filtering recommendation spells out why this is not the case
   [8]:

      Tracking the source of an attack is simplified when the source is
      more likely to be "valid."

6.3. Reverse Tunneling for Disparate Address Spaces

   There are security implications involved with the foreign agent's
   using link-layer information to select the proper reverse tunnel for
   mobile node packets (section A.3).  Unauthenticated link-layers allow
   a malicious mobile node to misuse another's existing reverse tunnel,
   and inject packets into the network.

   For this solution to be viable, the link-layer MUST securely
   authenticate traffic received by the foreign agent from the mobile
   nodes.  Unauthenticated link-layer technologies (for example shared
   ethernet) are not recommended to implement disparate address support.

7. IANA Considerations

   The Encapsulating Delivery Style extension defined in section 3.3 is
   a Mobile IP registration extension as defined in [1].  IANA assigned
   the value of 130 for this purpose at the time of the publication of
   RFC 2344.

   The Code values defined in section 3.4 are error codes as defined in
   [1].  They correspond to error values associated with rejection by
   the home and foreign agents.  At the time of the publication of RFC
   2344, IANA assigned codes 74-76 for the foreign agent rejections and
   codes 137-139 for the home agent rejections.  The code for 'delivery
   style not supported' has been assigned a value of 79 by the IANA for
   this purpose.

8. Acknowledgements

   The encapsulating style of delivery was proposed by Charlie Perkins.
   Jim Solomon has been instrumental in shaping this document into its
   present form.  Thanks to Samita Chakrabarti for helpful comments on
   disparate address space support, and for most of the text in section
   A.4.




Montenegro                  Standards Track                    [Page 18]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


References

   [1]  Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

   [2]  Perkins, C., "IP Encapsulation within IP", RFC 2003, October
        1996.

   [3]  Computer Emergency Response Team (CERT), "IP Spoofing Attacks
        and Hijacked Terminal Connections", CA-95:01, January 1995.
        Available via anonymous ftp from info.cert.org in
        /pub/cert_advisories.

   [4]  Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
        Work in Progress.

   [5]  Manuel Rodriguez, private communication, August 1995.

   [6]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
        November 1998.

   [7]  Kent, S. and R. Atkinson, "IP Encapsulating Payload", RFC 2406,
        November 1998.

   [8]  Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating
        Denial of Service Attacks which employ IP Source Address
        Spoofing", RFC 2267, January 1998.

   [9]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [10] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
        "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

   [11] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
        2486, January 1999.

   [12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J. and
        E. Lear, "Address Allocation for Private Internets", BCP 5, RFC
        1918, February 1996.

   [13] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC
        2890, August 2000.









Montenegro                  Standards Track                    [Page 19]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


Editor and Chair Addresses

   Questions about this document may be directed at:

   Gabriel E. Montenegro
   Sun Microsystems
   Laboratories, Europe
   29, chemin du Vieux Chene
   38240 Meylan
   FRANCE

   Phone: +33 476 18 80 45
   EMail: gab@sun.com


   The working group can be contacted via the current chairs:

   Basavaraj Patil
   Nokia Networks
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972-894-6709
   Fax :   +1 972-894-5349
   EMail:  Raj.Patil@nokia.com


   Phil Roberts
   Motorola
   1501 West Shure Drive
   Arlington Heights, IL 60004
   USA

   Phone:  +1 847-632-3148
   EMail:  QA3445@email.mot.com















Montenegro                  Standards Track                    [Page 20]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


Appendix A: Disparate Address Space Support

   Mobile IP [1] assumes that all the entities involved (mobile
   node, foreign agent and home agent) have addresses within the
   same globally routable address space.  In many deployment
   scenarios, when a mobile node leaves its home network it may
   wander into a region where its home address is not routable or
   known by the local routing fabric.  Similarly, the IP addresses
   of the foreign agent and the home agent may belong to disparate
   address spaces, which precludes their exchanging registration
   protocol messages directly.  These issues are possible
   particularly if the entities involved use addresses from the
   ranges specified in RFC1918 [12] to support private networks.

   Accurately speaking, the use of private addresses is not the
   only cause.  It may, in fact, be the most common, but the root of
   the problem lies in the use of disparate address spaces.  For
   example, corporations often have several properly allocated
   address ranges.  They typically advertise reachability to only a
   subset of those ranges, leaving the others for use exclusively
   within the corporate network.  Since these ranges are not
   routable in the general Internet, their use leads to the same
   problems encountered with "private" addresses, even though they
   are not taken from the ranges specified in RFC1918.

   Even if the mobile node, home agent and foreign agent all reside
   within the same address space, problems may arise if the
   correspondent node does not.  However, this problem is not
   specific to Mobile IP, and is beyond the scope of this
   document.  The next section limits even further the scope of the
   issues relevant to this document.  A subsequent section explains
   how reverse tunneling may be used to tackle them.

A.1. Scope of the Reverse Tunneling Solution

   Reverse tunneling (as defined in this document) may be used to
   cope with disparate address spaces, within the following
   constraints:

      -  There are no provisions to solve the case in which the
         correspondent node and the mobile node are in disparate
         address spaces.  This limits the scope of the problem to
         only those issues specific to Mobile IP.

      -  The foreign agent and the home agent are directly reachable
         to each other by virtue of residing in the same address
         space.  This limits the scope of the problem to only the
         simplest of cases.  This also implies that the registration



Montenegro                  Standards Track                    [Page 21]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


         protocol itself has a direct path between the foreign
         agent and the home agent, and, in this respect, is not
         affected by disparate address spaces.  This restriction
         also applies to mobile nodes operating with a co-located
         care-of address.  In this case, reverse tunneling is a
         complete and elegant solution.

      -  There are no additional protocol elements beyond those
         defined by Mobile IP [1] and reverse tunneling.  In
         particular, additional extensions to the registration
         requests or replies, or additional bits in the
         header--although potentially useful--are outside the scope
         of this document.

   In spite of the limitations, reverse tunneling may be used to
   solve the most common issues.  The range of problems that can be
   solved are best understood by looking at some simple diagrams:

   Figure A1: NON-ROUTABLE PACKETS IN DISPARATE ADDRESS SPACES

      Mc               Fa  Fb              Hb  Hc             Yc
   [MN]-----------------[FA]----------------[HA]---------------[Y]
        Addr space A          Addr space B       Addr space C

   In this diagram, there are three disparate address spaces:  A, B and
   C.  The home agent (HA) has one address each on address spaces B and
   C, and the foreign agent (FA), on address spaces A and B.  The mobile
   node's (MN) has a permanent address, Mc, within address space C.

   In the most common scenario both A and C are "private" address
   spaces, and B is the public Internet.

   Suppose MN sends a packet to correspondent node (Y) in its home
   network.  Presumably, MN has no difficulties delivering this packet
   to the FA, because it does so using layer 2 mechanisms.  Somehow, the
   FA must realize that this packet must be reverse tunneled, and it
   must fetch the proper binding to do so.  Possible mechanisms are
   outlined in section A.3.

   However, once the packet is in address space B it becomes non-
   routable.  Note that ingress filtering only exacerbates the problem,
   because it adds a requirement of topological significance to the
   source IP address in addition to the that of the destination address.
   As Mobile IP matures, others entities may be defined (for example,
   AAA servers).  Their addition places even more requirements on the
   address spaces in use.





Montenegro                  Standards Track                    [Page 22]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Reverse tunneling adds a topologically significant IP header to the
   packet (source IP address of Fb, destination of Hb) during its
   transit within address space B.  Assuming IP in IP encapsulation
   (although others, like GRE are also possible), this is what the
   packet looks like:

      Figure A2: IP IN IP REVERSE TUNNELED PACKET FROM FA TO HA

                        +-----------------+
                        |        +-------+|
                        | Fb->Hb | Mc->Yc||
                        |        +-------+|
                        +--------+--------+

   HA receives this packet, recovers the original packet, and since it
   is cognizant of address space C, delivers it to the appropriate
   interface.

   Of course, for this to happen, the care-of address registered by the
   MN is not the usual Fa, but Fb.  How this happens is outside the
   scope of this document.  Some possible mechanisms are:

      -  FA recognizes mobile nodes whose addresses fall within the
         private address ranges specified by RFC1918.  In this case, the
         foreign agent could force the use of Fb as the care-of address,
         perhaps by rejecting the initial registration request with an
         appropriate error message and supplemental information.

      -  FA could be configured to always advertise Fb as long as H->Fb
         and Fb->H are guaranteed to be valid forward and reverse
         tunnels, respectively, for all values of H.  Here, H is the
         address of any home agent whose mobile nodes may register via
         FA.

      -  FA could indicate that it supports disparate address spaces via
         a currently undefined 'P' bit in its advertisements, and an
         indication of the relevant address space for any or all of its
         care-of addressed by including an NAI [11] or a realm indicator
         (perhaps a variant of the NAI).  Alternatively, mobile nodes so
         configured could solicit the NAI or realm indicator information
         in response to advertisements with the 'P' bit set.

   Additionally, the mobile node needs to supply the appropriate address
   for its home agent: Hb instead of the usual Hc.  How this happens is
   outside the scope of this document.  Some possible mechanisms are:

      -  This determination could be triggered in response to using the
         foreign agent's Fb as the care-of address.



Montenegro                  Standards Track                    [Page 23]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


      -  The mobile node could always use Hb as its home agent address,
         specially (1) if Hb is routable within address space C, or (2)
         if MN is certain never to be at home (in some configurations,
         the mobile nodes are always roaming).

      -  The mobile node could be configured with different home agent
         addresses and their corresponding address space (perhaps
         indicated via an NAI [11] or a variant of it).

   Another major issue introduced by private addresses is that of two or
   more mobile nodes with the same numeric IP address:

      Figure A3: MOBILE NODES WITH CONFLICTING ADDRESSES

               Mc=M             H1b     H1c
          [MN1]-------+      +----[HA1]----+---------
                      |      |             | Address
                      |      |             | space C
         Address      |      |   Address   +----------
         Space       Fa-[FA]-Fb  Space
         A            |      |   B         +---------
                      |      |             | Address
                      |      |             | space D
          [MN2]-------+      +----[HA2]----+---------
               Md=M            H2b     H2d

   Suppose there are two address spaces A and B, and a foreign agent
   (FA) with interfaces on both.  There are two home agents (HA1 and
   HA2) in address space B, with addresses H1b and H2b, respectively.
   Each of the home agents has an interface in a private address space
   in addition to address space B: HA1 has H1c on C, and HA2 has H2d on
   D.  MN1 and MN2 are two mobile nodes with home addresses Mc and Md,
   corresponding to address space C and D, respectively.

   If Mc and Md are private addresses as defined in RFC1918, they may be
   numerically equivalent (both equal to M).  Because of this, the
   foreign agent can no longer rely on only the mobile node's home
   address to disambiguate amongst its different bindings.

A.2. Terminating Forward Tunnels at the Foreign Agent

   In figure A1, suppose the correspondent node Y sends a packet to the
   mobile node at address Mc.  The packet is intercepted by the home
   agent at Hc and tunneled towards the mobile node via address Fb.







Montenegro                  Standards Track                    [Page 24]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   Once the packet reaches FA (via address Fb), the foreign agent must
   identify which of its registered mobile nodes is the ultimate
   destination for the internal packet.  In order to do so, it needs to
   identify the proper binding via a tuple guaranteed to be unique among
   all of its mobile nodes.

   The unique tuple sufficient for demultiplexing IP in IP packets
   [IPIP] (protocol 4) is:

      -  destination IP address of the encapsulated (internal) header

         This is mobile node MN's home address (Mc in the above
         example).  At first glance, it seems like this is unique among
         all mobile nodes, but as mentioned above, with private
         addresses another mobile may have an address Md numerically
         equivalent to Mc.

      -  source IP address of the external header

         This, the remote end of the tunnel, is Hb in the above example.

      -  destination IP address of the external header

         This, the local end of the tunnel, is Fb in the above example.

   The three values above are learned from a successful registration and
   are the mobile node's home address, the home agent's address and the
   care-of address.  Thus, it is possible to identify the right binding.
   Once FA identifies the ultimate destination of the packet, Mc, it
   delivers the internal packet using link layer mechanisms.

   GRE packets [10] (protocol 47) are only handled if their Protocol
   Type field has a value of 0x800 (other values are outside the scope
   of this document), and are demultiplexed based on the same tuple as
   IP in IP packets.  In GRE terminology, the tuple is:

      -  destination IP address of the payload (internal) packet

      -  source IP address of the delivery (external) packet

      -  destination IP address of the delivery (external) packet

   Notice that the Routing, Sequence Number, Strict Source Route and Key
   fields have been deprecated from GRE [10].  However, a separate
   document specifies their use [13].






Montenegro                  Standards Track                    [Page 25]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


   The above tuples work for IP-in-IP or GRE encapsulation, and assume
   that the inner packet is in the clear.  Encapsulations which encrypt
   the inner packet header are outside the scope of this document.

A.3. Initiating Reverse Tunnels at the Foreign Agent

   In figure A3, suppose mobile node M1 sends a packet to a
   correspondent node in its home address space, C, and mobile node M2
   sends a packet to a correspondent node in its home address space, D.

   At FA, the source addresses for both packets will be seen as M, thus
   this is not sufficient information.  The unique tuple required to
   identify the proper binding is:

      -  link-layer information related to the MN

         This may be in the form of a MAC address, a PPP session (or
         incoming interface) or channel coding for a digital cellular
         service.  Device ID's can also be used in this context.

      -  source  IP address of the IP header.

         As was pointed out, this by itself is not guaranteed to be
         unique.

   This information must be established and recorded at registration
   time.  The above items are sufficient for the foreign agent to select
   the proper binding to use.  This, in turn, produces the address of
   the home agent, and the reverse tunneling options negotiated during
   the registration process.  The foreign agent can now proceed with
   reverse tunneling.

A.4. Limited Private Address Scenario

   The Limited Private Address Scenario (LPAS) has received much
   attention from the cellular wireless industry, so it is useful to
   define it and to clarify what its requirements are.

   LPAS is a subset of the disparate address space scenario discussed in
   this appendix.  This section explains how LPAS could be deployed
   given the current state of the Mobile IP specifications.










Montenegro                  Standards Track                    [Page 26]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


           Figure A4: EXAMPLE PRIVATE ADDRESS SCENARIO

        10.10.1.2
       +----+                IF1=COA1+-------+    HAA2 +-----+
       | MN1|------------------------|  FA   |---------| HA2 |
       +----+           +------------|       |         +-----+
                        |    IF2=COA2+-------+
                    +---+               |
                    |                   |
                 +-----+                |
                 | MN2 |                |
                 +-----+                |
                  10.10.1.2             |
                                        | HAA1
                                    +------+
                                    | HA1  |
                                    +------+

   The above figure presents a very simple scenario in which private
   addresses are used.  Here, "private addresses" are strictly those
   defined in RFC 1918 [12].  In this deployment scenario, the only
   entities that have private addresses are the mobile nodes.  Foreign
   agent and home agent addresses are publicly routable on the general
   Internet.  More specifically, the care-of addresses advertised by the
   foreign agents (COA1 and COA2 in Figure A4) and the home agent
   addresses used by mobile nodes in registration requests (HAA1 and
   HAA2 in Figure A4) are publicly routable on the general Internet.  As
   a consequence, any Mobile IP tunnels can be established between any
   home agent home address and any foreign agent care-of address.

   Also, note that two different mobile nodes (MN1 and MN2) with the
   same private address (10.10.1.2) are visiting the same foreign agent
   FA.  This is supported as long as MN1 and MN2 are serviced by
   different home agents.  Hence, from any given home agent's
   perspective, each mobile node has a unique IP address, even if it
   happens to be a private address as per RFC 1918.

   Operation in the presence of route optimization [4] is outside the
   scope of this document.

   Requirements for the above private address scenario:

      Mobile node requirements:

         Mobile nodes intending to use private addresses with Mobile IP
         MUST set the 'T' bit and employ reverse tunneling.  Mobile
         node's private addresses within a given address space MUST be
         unique.  Thus two mobile nodes belonging to a single home agent



Montenegro                  Standards Track                    [Page 27]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


         cannot have the same private addresses.  Thus, when receiving
         or sending tunneled traffic for a mobile node, the tunnel
         endpoints are used to disambiguate amongst conflicting mobile
         node addresses.

         If the mobile node happens to register with multiple home
         agents simultaneously through the same foreign agent, there
         must be some link-layer information that is distinct for each
         mobile node.  If no such distinct link-layer information is
         available, the mobile nodes MUST use unique address.

      Foreign agent requirements:

         All advertising interfaces of the foreign agent MUST have
         publicly routable care-of address.  Thus, a mobile node with a
         private address visits the foreign agent only in its publicly
         routable network.

         Foreign agents MUST support reverse tunneling in order to
         support private addressed mobile nodes.  If a foreign agent
         receives a registration request from a mobile node with a
         private address, and the mobile node has not set the 'T' bit,
         the foreign agent SHOULD reject it.

         When delivering packets to or receiving packets from mobile
         nodes, foreign agents MUST disambiguate among mobile node with
         conflicting private addresses by using link-layer information
         as mentioned previously (Appendix section A.2 and A.3).  A
         foreign agent in absence of route optimization, should make
         sure that two mobile nodes visiting the same foreign agent
         corresponds with each other through their respective home
         agents.

         If a foreign agent supports reverse tunneling, then it MUST
         support the simple scenario of private address support
         described in this section.

      Home agent requirements:

         Any home agent address used by mobile nodes in registration
         request MUST be a publicly routable address.  Home agents will
         not support overlapping private home addresses, thus each
         private home address of a mobile node registered with a home
         agent is unique.  When the 'T' bit is set in the registration
         request from the mobile node, the home agent MUST recognize and
         accept registration request from mobile nodes with private





Montenegro                  Standards Track                    [Page 28]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


         addresses. Also, the home agent SHOULD be able to assign
         private addresses out of its address pool to mobile nodes for
         use as home addresses.  This does not contravene home agent
         processing in section 3.8 of [1].

Appendix B: Changes from RFC2344

   This section lists the changes with respect to the previous version
   of this document (RFC2344).

   - Added Appendix A on support for Disparate Addresses spaces and
     private addresses.

   - Added the corresponding section (6.3) under 'Security
     Considerations'.

   - Made Encapsulating Delivery Support optional by demoting from
     a MUST to a should.  This also required defining a new error
     code 79 (assigned by IANA).

   - Mentioned the possibility of an admissible authentication
     extension which may be different from the Mobile-Home
     authentication extension.

   - An IANA considerations section was added.


























Montenegro                  Standards Track                    [Page 29]

RFC 3024        Reverse Tunneling for Mobile IP, revised    January 2001


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Montenegro                  Standards Track                    [Page 30]