summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3519.txt
blob: f4b80c852d93756e1302b4e261c550f3259963b9 (plain) (blame)
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
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
Network Working Group                                       H. Levkowetz
Request for Comments: 3519                                   ipUnplugged
Category: Standards Track                                     S. Vaarala
                                                                 Netseal
                                                              April 2003


    Mobile IP Traversal of Network Address Translation (NAT) Devices

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 (2003).  All Rights Reserved.

Abstract

   Mobile IP's datagram tunnelling is incompatible with Network Address
   Translation (NAT).  This document presents extensions to the Mobile
   IP protocol and a tunnelling method which permits mobile nodes using
   Mobile IP to operate in private address networks which are separated
   from the public internet by NAT devices.  The NAT traversal is based
   on using the Mobile IP Home Agent UDP port for encapsulated data
   traffic.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  2
       1.1   Terminology . . . . . . . . . . . . . . . . . . . . . .  2
       1.2   Problem description . . . . . . . . . . . . . . . . . .  3
       1.3   Assumptions . . . . . . . . . . . . . . . . . . . . . .  4
   2.  NAT Traversal Overview. . . . . . . . . . . . . . . . . . . .  5
       2.1   Basic Message Sequence. . . . . . . . . . . . . . . . .  5
   3.  New Message Formats . . . . . . . . . . . . . . . . . . . . .  6
       3.1   UDP Tunnel Request Extension. . . . . . . . . . . . . .  6
             3.1.1 F (Force) Flag. . . . . . . . . . . . . . . . . .  7
             3.1.2 R (Registration through FA Required) flag . . . .  8
             3.1.3 Reserved Fields . . . . . . . . . . . . . . . . .  8
             3.1.4 Encapsulation . . . . . . . . . . . . . . . . . .  8
             3.1.5 Mobile IP Registration Bits . . . . . . . . . . .  9
       3.2   UDP Tunnel Reply Extension. . . . . . . . . . . . . . .  9
             3.2.1 Reply Code. . . . . . . . . . . . . . . . . . . . 10



Levkowetz & Vaarala         Standards Track                     [Page 1]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


       3.3   MIP Tunnel Data Message . . . . . . . . . . . . . . . . 10
       3.4   UDP Tunnelling Flag in Agent Advertisements . . . . . . 11
       3.5   New Registration Reply Codes. . . . . . . . . . . . . . 12
   4.  Protocol Behaviour. . . . . . . . . . . . . . . . . . . . . . 12
       4.1   Relation to standard MIP tunnelling . . . . . . . . . . 12
       4.2   Encapsulating IP Headers in UDP . . . . . . . . . . . . 13
       4.3   Decapsulation . . . . . . . . . . . . . . . . . . . . . 15
       4.4   Mobile Node Considerations. . . . . . . . . . . . . . . 15
       4.5   Foreign Agent Considerations. . . . . . . . . . . . . . 16
       4.6   Home Agent Considerations . . . . . . . . . . . . . . . 18
             4.6.1 Error Handling. . . . . . . . . . . . . . . . . . 19
       4.7   MIP signalling versus tunnelling. . . . . . . . . . . . 20
       4.8   Packet fragmentation. . . . . . . . . . . . . . . . . . 21
       4.9   Tunnel Keepalive. . . . . . . . . . . . . . . . . . . . 21
       4.10  Detecting and compensating for loss of NAT mapping. . . 22
       4.11  Co-located registration through FA. . . . . . . . . . . 24
   5.  Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
       5.1   Movement Detection and Private Address Aliasing . . . . 24
       5.2   Mobility Binding Lifetime . . . . . . . . . . . . . . . 25
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 26
       6.1   Traffic Redirection Vulnerabilities . . . . . . . . . . 27
             6.1.1 Manipulation of the Registration
                   Request Message . . . . . . . . . . . . . . . . . 27
             6.1.2 Sending a Bogus Keepalive Message . . . . . . . . 27
       6.2   Use of IPsec. . . . . . . . . . . . . . . . . . . . . . 28
       6.3   Firewall Considerations . . . . . . . . . . . . . . . . 28
   7.  UNSAF Considerations. . . . . . . . . . . . . . . . . . . . . 28
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
   9.  Intellectual Property Rights. . . . . . . . . . . . . . . . . 30
   10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 31
   11. Normative References. . . . . . . . . . . . . . . . . . . . . 31
   12. Informative References. . . . . . . . . . . . . . . . . . . . 32
   13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 33
   14. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 34

1. Introduction

1.1 Terminology

   The Mobile IP related terminology described in RFC 3344 [10] is used
   in this document.  In addition, the following terms are used:

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






Levkowetz & Vaarala         Standards Track                     [Page 2]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


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

   NAT
      Network Address Translation.  "Traditional NAT would allow hosts
      within a private network to transparently access hosts in the
      external network, in most cases.  In a traditional NAT, sessions
      are uni-directional, outbound from the private network." -- RFC
      2663 [11].  Basic NAT and NAPT are two varieties of NAT.

   Basic NAT
      "With Basic NAT, a block of external addresses are set aside for
      translating addresses of hosts in a private domain as they
      originate sessions to the external domain.  For packets outbound
      from the private network, the source IP address and related fields
      such as IP, TCP, UDP and ICMP header checksums are translated.
      For inbound packets, the destination IP address and the checksums
      as listed above are translated." -- RFC 2663 [11].

   NAPT
      Network Address Port Translation.  "NAPT extends the notion of
      translation one step further by also translating transport
      identifier (e.g., TCP and UDP port numbers, ICMP query
      identifiers).  This allows the transport identifiers of a number
      of private hosts to be multiplexed into the transport identifiers
      of a single external address.  NAPT allows a set of hosts to share
      a single external address.  Note that NAPT can be combined with
      Basic NAT so that a pool of external addresses are used in
      conjunction with port translation." -- RFC 2663 [11].

   In this document, the more general term NAT is used to cover both
   NATs and NAPTs.  In most deployment cases today, we believe that the
   NATs used are of the NAPT variety.

   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 BCP 14, RFC 2119 [6].

1.2 Problem description

   A basic assumption that Mobile IP [10] makes is that mobile nodes and
   foreign agents are uniquely identifiable by a globally routable IP
   address.  This assumption breaks down when a mobile node attempts to
   communicate from behind a NAT.






Levkowetz & Vaarala         Standards Track                     [Page 3]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   Mobile IP relies on sending traffic from the home network to the
   mobile node or foreign agent through IP-in-IP tunnelling.  IP nodes
   which communicate from behind a NAT are reachable only through the
   NAT's public address(es).  IP-in-IP tunnelling does not generally
   contain enough information to permit unique translation from the
   common public address(es) to the particular care-of address of a
   mobile node or foreign agent which resides behind the NAT; in
   particular there are no TCP/UDP port numbers available for a NAT to
   work with.  For this reason, IP-in-IP tunnels cannot in general pass
   through a NAT, and Mobile IP will not work across a NAT.

   Mobile IP's Registration Request and Reply will on the other hand be
   able to pass through NATs and NAPTs on the mobile node or foreign
   agent side, as they are UDP datagrams originated from the inside of
   the NAT or NAPT.  When passing out, they make the NAT set up an
   address/port mapping through which the Registration Reply will be
   able to pass in to the correct recipient.  The current Mobile IP
   protocol does however not permit a registration where the mobile
   node's IP source address is not either the CoA, the Home Address, or
   0.0.0.0.

   What is needed is an alternative data tunnelling mechanism for Mobile
   IP which will provide the means needed for NAT devices to do unique
   mappings so that address translation will work, and a registration
   mechanism which will permit such an alternative tunnelling mechanism
   to be set up when appropriate.

   This mechanism will address 3 different scenarios:

   -  A mobile node with co-located address behind a NAT; no FA

   -  A mobile node registered with an FA where both the mobile node and
      the FA are behind the same NAT

   -  A mobile node with co-located address using an FA which demands
      that registrations pass through the FA (sets the "R" bit) where
      both the mobile node and the FA are behind the same NAT

1.3 Assumptions

   The primary assumption in this document is that the network allows
   communication between an UDP port chosen by the mobile node and the
   home agent UDP port 434.  If this assumption does not hold, neither
   Mobile IP registration nor data tunnelling will work.

   This document does NOT assume that mobility is constrained to a
   common IP address space.  On the contrary, the routing fabric between
   the mobile node and the home agent may be partitioned into a



Levkowetz & Vaarala         Standards Track                     [Page 4]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   "private" and a "public" network, and the assumption is that some
   mechanism is needed in addition to vanilla Mobile IP according to RFC
   3344 [10] in order to achieve mobility within disparate IP address
   spaces.

   For a more extensive discussion of the problems with disparate
   address spaces, and how they may be solved, see RFC 3024 [9].

   The reverse tunnels considered here are symmetric, that is, they use
   the same configuration (encapsulation method, IP address endpoints)
   as the forward tunnel.

2. NAT Traversal Overview

   This section gives a brief overview of the MIP UDP tunnelling
   mechanism which may be used to achieve NAT traversal for Mobile IP.

   In MIP UDP tunnelling, the mobile node may use an extension
   (described below) in its Registration Request to indicate that it is
   able to use Mobile IP UDP tunnelling instead of standard Mobile IP
   tunnelling if the home agent sees that the Registration Request seems
   to have passed through a NAT.  The home agent may then send a
   registration reply with an extension indicating acceptance (or
   denial).  After assent from the home agent, MIP UDP tunnelling will
   be available for use for both forward and reverse tunnelling.  UDP
   tunnelled packets sent by the mobile node use the same ports as the
   registration request message.  In particular, the source port may
   vary between new registrations, but remains the same for all
   tunnelled data and re-registrations.  The destination port is always
   434.  UDP tunnelled packets sent by the home agent uses the same
   ports, but in reverse.

2.1 Basic Message Sequence

   The message sequence diagram below exemplifies setting up and using a
   Mobile IP UDP tunnel as described in this document.  The tunnel is
   set up by the use of specific extensions in the initial Mobile IP
   Registration Request and Reply exchange.  Thereafter, any traffic
   from the home agent to the mobile node is sent through the UDP
   tunnel.  The mobile node may at its discretion use the UDP tunnel for
   reverse tunnelling or not, although in most cases where MIP UDP
   tunnelling is needed, reverse tunnelling will also be needed.









Levkowetz & Vaarala         Standards Track                     [Page 5]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   mobile node            NAT           home agent
        |                  |                  |
        |                  |                  |
        | Registration     |                  |
        | Request with     |                  |
        |-----------------///--------------->>|
        |UDP Tunnel Request|                  |
        |                  |                  +
        |                  |                  || IP Source and
        |                  |                  || CCoA address
        |                  |                  || discrepancy
        |                  |                  || seen
        |                  | Registration     +
        |                  | Reply with       |
        |<<---------------///-----------------|
        |                  | UDP Tunnel Reply.|
        |                  |                  |
        | UDP tunnelled pkg|                  |
        |=================///===============>>|
        |                  | UDP tunnelled pkg|
        |<<===============///=================|
        |                  |                  ||absence of
        |                  |                  ||traffic for
        |                  |                  ||UDP keepalive
        | UDP keepalive    |                  ||period
        |-----------------///--------------->>+
        .                  .                  +
        .                  .                  .
        .                  .                  .

3. New Message Formats

3.1 UDP Tunnel Request Extension

   This extension is a skippable extension.  It signifies that the
   sender is capable of handling MIP UDP tunnelling, and optionally that
   a particular encapsulation format is requested in the MIP UDP tunnel.
   The format of this extension is as shown below.  It adheres to the
   short extension format described in [10].

    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     |    Sub-Type   |   Reserved 1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|R| Reserved 2| Encapsulation |          Reserved 3           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Levkowetz & Vaarala         Standards Track                     [Page 6]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   Type                144

   Length              6.  Length in bytes of this extension, not
                       including the Type and Length bytes.

   Sub-Type            0

   Reserved 1          Reserved for future use.  MUST be set to 0 on
                       sending, MUST be ignored on reception.

   F                   F (Force) flag.  Indicates that the mobile
                       node wants to force MIP UDP tunnelling to be
                       established.

   R                   R (Registration through FA Required) flag.
                       Indicates that the R bit was set in the FA's
                       Agent Advertisement.  Registration is being
                       made using a co-located care-of address, but
                       through the FA.

   Reserved 2          Reserved for future use.  MUST be set to 0 on
                       sending, MUST be ignored on reception.

   Encapsulation       Indicates the type of tunnelled data, using
                       the same numbering as the IP Header Protocol
                       Field.

   Reserved 3          Reserved for future use.  MUST be set to 0 on
                       sending, MUST be verified as 0 on receipt;
                       otherwise the extension must be handled as not
                       understood and silently skipped.

3.1.1 F (Force) Flag

   Indicates that the mobile node wants to use traversal regardless of
   the outcome of NAT detection performed by the home agent.  This is
   useful if the route between the mobile node and the home agent works
   for Mobile IP signalling packets, but not for generic data packets
   (e.g., because of firewall filtering rules).  If the home agent
   supports this protocol, it SHOULD either accept the traversal and
   reply with a UDP Tunnel Reply Extension or reject the Registration
   Request.  In case of the registration failing, the Home Agent SHOULD
   send a Registration Reply with Code field set to 129
   ("administratively prohibited").







Levkowetz & Vaarala         Standards Track                     [Page 7]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   If the HA does not understand the UDP Tunnel Request Extension, it
   will silently discard it, and if everything else is fine, it will
   reply with a registration reply with reply code 0 (registration
   accepted), but without any UDP Tunnel Reply Extension.  In this case,
   the mobile node MUST NOT use MIP UDP tunnelling.

3.1.2 R (Registration through FA Required) flag

   This flag MUST be set by the mobile node when it is using a co-
   located address, but registering through an FA because it has
   received an Agent Advertisement with the 'R' bit set.

3.1.3 Reserved Fields

   The 'Reserved 1' and 'Reserved 2' fields must be ignored on receipt,
   while the 'Reserved 3' field must be 0 on receipt, otherwise this
   extension MUST be handled as not understood and silently skipped.
   This permits future additions to this extension to be made which
   either can co-exist with old implementations, or will force a
   rejection of the extension from an old implementation.

3.1.4 Encapsulation

   The 'Encapsulation' field defines the mode of encapsulation requested
   if MIP UDP tunnelling is accepted by the home agent.  This field uses
   the same values as the IP header Protocol field:

      4     IP header (IP-in-UDP tunnelling) RFC 2003 [4]

      47    GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]

      55    Minimal IP encapsulation header RFC 2004 [5]

   If the home agent finds that UDP tunnelling is not needed, the
   encapsulation will be determined by the 'M' and 'G' flags of the
   registration request; but if the home agent finds that MIP UDP
   tunnelling should be done, the encapsulation is determined from the
   value of the Encapsulation field.  If the value of this field is
   zero, it defaults to the value of 'M' and 'G' fields in the
   Registration Request message, but if it is non-zero, it indicates
   that a particular encapsulation is desired.










Levkowetz & Vaarala         Standards Track                     [Page 8]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


3.1.5 Mobile IP Registration Bits

   The Mobile IP registration bits S, B, D, M, G and T retain their
   meaning as described in RFC 3344 [10] and RFC 3024 [9] (except that
   the significance of the M and G bits may be modified by the
   Encapsulation field when MIP UDP tunnelling is used, as described
   above).  The use of the M and G bits together with MIP UDP tunnelling
   is also touched upon in Section 4.1.

   When the MN requests MIP UDP tunnelling, the 'D' bit (Decapsulation
   by the mobile node) MUST be set, otherwise UDP tunnelling would not
   be meaningful.

   Both the MN and the FA SHOULD set the 'T' bit when requesting MIP UDP
   tunnelling, even if not all traffic will be reverse tunnelled.  This
   ensures that a HA which is not prepared to accept reverse tunnelling
   will not accept a registration which may later turn out to be
   unusable.  Also see the discussion of use of the 'T' bit in Foreign
   Agent Considerations (Section 4.5).

3.2 UDP Tunnel Reply Extension

   This extension is a non-skippable extension.  It is sent in reply to
   a UDP Tunnel Request extension, and indicates whether or not the HA
   will use MIP UDP tunnelling for the current mobility binding.  The
   format of this extension is as shown below.

    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     |    Sub-Type   |  Reply Code   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|        Reserved             |     Keepalive Interval        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type                44

   Length              6.  Length in bytes of this extension, not
                       including the Type and Length bytes.

   Sub-Type            0

   Reply Code          Indicates whether the HA assents or declines
                       to use UDP tunnelling for the current mobility
                       binding.  See Section 3.2.1 below.






Levkowetz & Vaarala         Standards Track                     [Page 9]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   F                   F (Forced) flag.  Indicates that tunnelling is
                       being forced because the F flag was set in the
                       tunnelling request, irrespective of the
                       detection of a NAT or not.

   Keepalive Interval  Specifies the NAT keepalive interval that the
                       mobile node SHOULD use.  A keepalive packet
                       SHOULD be sent if Keepalive Interval seconds
                       have elapsed without any signalling or data
                       traffic being sent.  If this field is set to
                       0, the mobile node MUST use its default
                       configured keepalive interval.

   Reserved            Reserved for future use.  MUST be set to 0 on
                       sending, MUST be ignored on reception.

3.2.1 Reply Code

   The Reply Code field of the UDP Tunnel Reply Extension indicates if
   UDP tunnelling have been accepted and will be used by the HA.  Values
   in the range 0 ..  63 indicate assent, i.e., that tunnelling will be
   done, while values in the range 64 ..  255 indicate that tunnelling
   should not be done.  More information may be given by the value of
   the response code.

   The following response codes are defined for use in the code field of
   the UDP Tunnel Reply Extension:

      0     Will do tunnelling

      64    Tunnelling declined, reason unspecified

3.3 MIP Tunnel Data Message

   This MIP message header serves to differentiate traffic tunnelled
   through the well-known port 434 from other Mobile IP messages, e.g.,
   Registration Requests and Registration Replies.

    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      |  Next Header  |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type                4






Levkowetz & Vaarala         Standards Track                    [Page 10]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   Next Header         Indicates the type of tunnelled data, using
                       the same numbering as the IP Header Protocol
                       Field.

   Reserved            Reserved for future use.  MUST be set to 0 on
                       sending, MUST be ignored on reception.

   The Next Header field uses the same values as the IP header Protocol
   field.  Immediately relevant for use with Mobile IP are the following
   values:

       4    IP header (IP-in-UDP tunnelling) RFC 2003 [4]

      47    GRE Header (GRE-in-UDP tunnelling) RFC 2784 [8]

      55    Minimal IP encapsulation header RFC 2004 [5]

   The receiver of a tunnelled packet MUST check that the Next Header
   value matches the tunnelling mode established for the mobility
   binding with which the packet was sent.  If a discrepancy is
   detected, the packet MUST be dropped.  A log entry MAY be written,
   but in this case the receiver SHOULD ensure that the amount of log
   entries written is not excessive.

   In addition to the encapsulation forms listed above, the MIP UDP
   tunnelling can potentially support other encapsulations, by use of
   the Next Header field in the MIP Tunnel Data Header and the
   Encapsulation Header field of the UDP Tunnel Request Extension
   (Section 3.1).

3.4 UDP Tunnelling Flag in Agent Advertisements

   The only change to the Mobility Agent Advertisement Extension defined
   in RFC 3344 [10] is a flag indicating that the foreign agent
   generating the Agent Advertisement supports MIP UDP Tunnelling.  The
   flag is inserted after the flags defined in [10].

    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|r|T|U|   reserved  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  zero or more Care-of Addresses               |
   |                              ...                              |





Levkowetz & Vaarala         Standards Track                    [Page 11]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   The flag is defined as follows:

   U     UDP Tunnelling support.  This Agent supports MIP UDP Tunnelling
         as specified in this document.  This flag SHOULD be set in
         advertisements sent by a foreign agent which supports MIP UDP
         tunnelling and is situated behind a NAT.  It MUST NOT be set in
         advertisements from foreign agents which are not situated
         behind a NAT, and thus has no need to advertise the capability.

3.5 New Registration Reply Codes

   One new registration reply code is defined:

      ERROR_HA_UDP_ENCAP_UNAVAIL      Requested UDP tunnel encapsulation
                                      unavailable

   This is used by the HA to distinguish the registration denial caused
   by an unavailable UDP tunnel encapsulation mode from a denial caused
   by unavailable standard tunnel encapsulation requested by use of the
   'T' bit together with either 'M' or 'G' bit.

4. Protocol Behaviour

4.1 Relation to standard MIP tunnelling

   The default encapsulation mode for MIP UDP tunnelling is IP-in-UDP
   encapsulation.  The mobile node MAY request alternative forms of
   encapsulation to be used with UDP tunnelling by setting the 'M' bit
   and/or the 'G' bit of a Mobile IP registration request, or by
   explicitly requesting a particular encapsulation for the MIP UDP
   tunnel by using the Encapsulation field.  The M and G bits retain the
   meaning as described in RFC 3344 [10] within the context of MIP UDP
   tunnelling.  The UDP tunnelling version of the classic MIP
   encapsulation methods can be summarised as:

   IP in UDP.  When Mobile IP UDP tunnelling is used, this is the
      default encapsulation type.  Any home agent and mobile node that
      implements Mobile IP UDP tunnelling MUST implement this
      encapsulation type.

   GRE in UDP.  If the 'G' bit is set in a registration request and
      the Encapsulation field is zero, the mobile node requests that its
      home agent use GRE encapsulation [3] for datagrams tunnelled to
      the mobile node.  If MIP UDP tunnelling is also requested and
      accepted, GRE-in-UDP encapsulation SHALL be used in the same cases
      as GRE in IP encapsulation would be used if the MIP UDP tunnelling
      had not been requested.




Levkowetz & Vaarala         Standards Track                    [Page 12]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   Minimal encapsulation in UDP.  If the 'M' bit is set and the
      Encapsulation field is zero, the mobile node requests that its
      home agent use minimal encapsulation [5] for datagrams tunnelled
      to the mobile node.  If MIP UDP tunnelling is also used, minimal
      encapsulation in UDP SHALL be used in the same cases as minimal
      encapsulation according to RFC 2004 [5] would be used if the MIP
      UDP tunnelling had not been requested.

   When the Encapsulation field is non-zero, a particular encapsulation
   format is requested for the MIP UDP tunnel.  If tunnelling is
   indicated, the request MUST either be accepted using the requested
   encapsulation, or rejected with the error code
   ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel encapsulation
   unavailable" defined in Section 3.5.  On receipt of this error, the
   mobile node MAY choose to send a new Registration Request with
   different requirements on MIP UDP tunnelling encapsulation.

4.2 Encapsulating IP Headers in UDP

   MIP IP-in-UDP tunnelling, or UDP tunnelling for short, is done in a
   manner analogous to that described for IP-in-IP tunnelling in RFC
   2003 [4], with the exception of the addition of an UDP header [1] and
   MIP Message header [10] between the outer and inner IP header.

   Mobile IP Registration Requests and Registration Replies are already
   in the form of UDP messages, and SHALL NOT be tunnelled even when MIP
   IP-in-UDP tunnelling is in force.
























Levkowetz & Vaarala         Standards Track                    [Page 13]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   To encapsulate an IP datagram using MIP IP-in-UDP encapsulation, an
   outer IP header [2], UDP header [1] and MIP Message header [10] is
   inserted before the datagram's existing IP header, as follows:

                                       +---------------------------+
                                       |                           |
                                       |      Outer IP Header      |
                                       +---------------------------+
                                       |                           |
                                       |        UDP Header         |
                                       +---------------------------+
                                       |      MIP Tunnel Data      |
                                       |      Message Header       |
   +---------------------------+       +---------------------------+
   |                           |       |                           |
   |         IP Header         |       |         IP Header         |
   +---------------------------+ ====> +---------------------------+
   |                           |       |                           |
   |         IP Payload        |       |         IP Payload        |
   |                           |       |                           |
   |                           |       |                           |
   +---------------------------+       +---------------------------+

   The outer IP header Source Address and Destination Address, together
   with the UDP header Source Port and Destination Port, identify the
   "endpoints" of the tunnel.  The inner IP header Source Address and
   Destination Addresses identify the original sender and the recipient
   of the datagram, respectively.  The inner IP header is not changed by
   the encapsulator, except to decrement the TTL by one if the
   tunnelling is being done as part of forwarding the datagram as noted
   in RFC 2003 [4], and remains unchanged during its delivery to the
   tunnel exit point.  No change to IP options in the inner header
   occurs during delivery of the encapsulated datagram through the
   tunnel.  Note that the security options of the inner IP header MAY
   affect the choice of security options for the encapsulating (outer)
   IP header.

   Minimal Encapsulation and GRE encapsulation is done in an analogous
   manner, following RFC 2004 [5] for Minimal Encapsulation and RFC 2784
   [8] for GRE Encapsulation, but using outer IP, UDP and MIP headers in
   place of the outer IP header.

   All other provisions and requirements of RFC 2003 [4] and RFC 3024
   [9] are in force, except in one respect, as covered in Packet
   Fragmentation (Section 4.8).






Levkowetz & Vaarala         Standards Track                    [Page 14]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


4.3 Decapsulation

   Before decapsulation is actually done, the decapsulating node MUST
   verify that the outer IP addresses and UDP port numbers exactly match
   the values used for the tunnel, with the exception of tunnels that
   are "half bound" (as described in Section 4.11) where the source UDP
   port can change.

   IP-in-UDP encapsulated traffic is decapsulated simply by stripping
   off the outer IP, UDP and MIP header, which leaves the original IP
   packet which is forwarded as is.

   Minimal IP encapsulation is processed by the receiver conceptually as
   follows.  First, the UDP and the Mobile IP headers are removed from
   the packet, and the Protocol field of the IP header replaced with the
   Next Header field in the MIP Tunnel Data header.  Second, the
   remaining IP header total length and checksum are adjusted to match
   the stripped packet.  Third, ordinary minimal IP encapsulation
   processing is done.

   GRE encapsulated traffic is processed according to RFC 2784 [8] and
   RFC 1701 [3], with the delivery header consisting of the outer IP,
   UDP and MIP headers.

4.4 Mobile Node Considerations

   The UDP Tunnel Request Extension MAY be used in a Mobile IP
   Registration Request from the mobile node to the home agent when the
   mobile node uses a co-located care-of address.  It SHALL NOT be used
   by the mobile node when it is registering with a foreign agent care-
   of address.

   The purpose of this extension is to indicate to the home agent that
   the mobile node is able to accept MIP UDP tunnelling if the home
   agent has an indication that the mobile node resides behind a NAT or
   NAPT.  It thus functions as a conditional solicitation for the use of
   MIP UDP tunnelling.

   As per Section 3.2 and 3.6.1.3 of RFC 3344 [10], the mobile node MUST
   place this Extension before the Mobile-Home Authentication Extension
   in registration messages, so that it is covered by the Mobile-Home
   Authentication Extension.

   If the mobile node includes the UDP Tunnel Request extension in a
   registration request, but receives a registration reply without a UDP
   Tunnel Reply extension, it MUST assume that the HA does not





Levkowetz & Vaarala         Standards Track                    [Page 15]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   understand this extension, and it MUST NOT use UDP tunnelling.  If
   the mobile node is in fact behind a NAT, the registration may then
   succeed, but traffic will not be able to traverse the NAT.

   When the mobile node sends MIP UDP tunnelled data, it MUST use the
   same UDP source port as was used for the most recent registration
   request.

   When the mobile node re-registers without having moved, it SHOULD
   take care to use the same source port as was used for the original
   registration of the current mobility binding.  Otherwise, while the
   home agent would change destination port on acceptance of the new
   registration, and the mobile node would presumably start listening on
   the new port, the packets in flight from the home agent at the time
   of change will be dropped when arriving at the mobile node's old
   port.  (This does not mean that the home agent should refuse a
   registration request using MIP UDP tunnelling where a new port have
   been used, as this might be the result of the NAT dropping state, the
   mobile node re-booting, changing interface, etc.)

   If a mobile node is registering through a foreign agent but using a
   co-located care-of address, and the agent advertisement from the
   foreign agent had the 'U' bit set, the mobile node MUST set the 'R'
   flag in its UDP Tunnel Request Extension, in order to make the HA use
   MIP UDP tunnelling.  In this case, the mobile node also MUST send a
   keepalive as soon as its registration has been accepted.

   If a mobile node is registering through a foreign agent but using a
   co-located care-of address, and the agent advertisement from the
   foreign agent does not have the 'U' bit set, the mobile node MUST NOT
   include a UDP Tunnel Request Extension in the registration request.

4.5 Foreign Agent Considerations

   The UDP Tunnel Request Extension MAY be used by a foreign agent when
   it is forwarding a Mobile IP Registration Request to a home agent,
   when the foreign agent is situated behind a NAT or has some other
   compelling reason to require MIP UDP tunnelling.

   The purpose of this extension is to indicate to the home agent that
   the foreign agent is able to accept MIP UDP tunnelling if the home
   agent has an indication that the foreign agent resides behind a NAT
   or NAPT.  It thus functions as a conditional solicitation for the use
   of MIP UDP tunnelling.

   A foreign agent which requires the mobile node to register through a
   foreign agent by setting the 'R' bit in the agent advertisement, MUST
   NOT add the UDP Tunnel Request Extension when forwarding a



Levkowetz & Vaarala         Standards Track                    [Page 16]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   registration request which uses a co-located care-of address, as this
   will lead to a UDP tunnel being set up from the home agent to the
   foreign agent instead of to the mobile node.

   As per Section 3.2 and 3.7.2.2 of RFC 3344 [10], the foreign agent
   when using this extension MUST place it after the Mobile-Home
   Authentication Extension in registration messages.  If the foreign
   agent shares a mobility security association with the home agent and
   therefore appends a Foreign-Home Authentication Extension, the UDP
   Tunnel Request Extension MUST be placed before the Foreign-Home
   Authentication Extension.

   As the home agent detects the presence of a NAT in the path between
   the sender and itself by seeing a mismatch between the IP source
   address and the care-of address given in the registration request, it
   is REQUIRED that the foreign agent, when using this extension, sends
   the registration request with an IP source address matching the
   care-of address.

   A foreign agent using MIP UDP tunnelling to a home agent because the
   FA is situated behind a NAT may be configured to encourage reverse
   tunnelling, or be neutral about it, depending on the characteristics
   of the NAT.  If the NAT translates all source addresses of outgoing
   packets to its own public address, it will not be possible to
   maintain sessions when moving away from this network if the mobile
   node has used triangular routing instead of reverse tunnelling.  On
   the other hand, if it is known that the NAT is smart enough to not
   translate publicly routable source addresses, AND does not do ingress
   filtering, triangular routing may succeed.  The leg from the home
   agent to the foreign agent will still use MIP UDP tunnelling to pass
   through the NAT.

   Therefore, if it is known when configuring a foreign agent behind a
   NAT that the NAT will translate public as well as private addresses,
   or it is known that ingress filtering is being done between the
   private and public networks, the foreign agent SHOULD reply to
   registration requests which don't have the 'T' bit set with a reply
   code 75, "reverse tunnel is mandatory and 'T' bit not set".

   Conversely, if it is known that the NAT is smart about not
   translating public addresses, and no ingress filtering is done, so it
   is reasonable to believe that a mobile node with a publicly routable
   address may be able to keep up sessions when moving to or from this
   network, the foreign agent MAY be configured to forward registration
   requests even if they don't have the 'T' bit set.






Levkowetz & Vaarala         Standards Track                    [Page 17]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   If the behaviour of the NAT is unknown in this respect, it SHOULD be
   assumed that it will translate all addresses, thus the foreign agent
   SHOULD be configured to reply to registration requests which don't
   have the 'T' bit set with a reply code 75, "reverse tunnel is
   mandatory and 'T' bit not set".

4.6 Home Agent Considerations

   The purpose of the MIP UDP Tunnel Reply Extension is to indicate
   whether or not the home agent accepts the use of MIP UDP tunnelling
   for this mobility binding, and to inform the mobile node or foreign
   agent of the suggested tunnel keepalive interval to be used.

   The UDP Tunnel Reply Extension MUST be used in a Mobile IP
   Registration Reply from the home agent to the mobile node when it has
   received and accepted a UDP Tunnel Request (Section 3.1) from a
   mobile node.

   The home agent MUST use a mismatch between source IP address and
   care-of address in the Mobile IP Registration Request message as the
   indication that a mobile node may reside behind a NAT.  If the
   Registration Request also contains the UDP Tunnel Request extension
   without the 'R' flag set, and the home agent is capable of, and
   permits MIP UDP tunnelling, the home agent SHALL respond with a
   registration reply containing an assenting UDP Tunnel Reply Extension
   as described in Section 3.2.  If the 'R' flag is set, special
   considerations apply, as described below.

   If the home agent receives a Registration Request with matching
   source IP address and co-located care-of address which contains a MIP
   UDP Tunnel Request Extension, the home agent SHOULD respond with a
   Registration Reply containing a declining UDP Tunnel Reply - unless
   tunnelling has been explicitly requested by the mobile node using the
   'F' flag as described in Section 3.1.

   If the home agent assents to UDP tunnelling, it MUST use the source
   address of the registration request as the effective care-of address,
   rather than the care-of address given in the registration request,
   except in the case where the 'R' flag is set in the UDP Tunnel
   Request Extension.

   If the home agent receives a Registration Request with the 'R' flag
   set in the UDP Tunnel Request Extension, it SHOULD reply with an
   assenting UDP Tunnel Reply Extension if it is capable of, and permits
   MIP UDP tunnelling.  In this case, however, the source address and
   port of the registration request may be a NAT'ed version of the
   foreign agent source address and port.  In order to direct tunnelled
   traffic correctly to the mobile node, the home agent MUST wait for



Levkowetz & Vaarala         Standards Track                    [Page 18]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   the first keepalive packet from the mobile node to arrive, before it
   can send traffic back to the correct NAT port (the one which is
   mapped to the MN).  In this case, the home agent MUST check that the
   outer source address (but not the port) of this keepalive packet is
   identical with the source address of the corresponding registration
   request.  The inner source address (that of the encapsulated ICMP
   echo request) MUST be the home address of the mobile node, and the
   inner destination address MUST be that of the home agent.  If all
   this holds, the outer source address and port of this keepalive
   packet SHALL be used by the HA as the outer destination address and
   port of the MIP UDP tunnel when forwarding traffic to the mobile
   node.

   The home agent SHOULD be consistent in acknowledging support for UDP
   tunnelling or not.  A home agent which understands the UDP Tunnel
   Request Extension and is prepared to respond positively to such a
   request SHOULD also respond with a UDP Tunnel Reply Extension
   containing a declining reply code if use of MIP UDP tunnelling is not
   indicated for a session.  The mobile node MUST NOT assume such
   behaviour from the home agent, since the home agent may undergo a
   software change with reboot, a policy change or a replacement; and
   consequently a change of behaviour.

4.6.1 Error Handling

   The following actions take place when things go wrong.

   The HA does not support the UDP Tunnel Request extension:

      The home agent ignores the extension and proceeds normally, which
      would be to refuse the registration if the IP source address does
      not match the care-of address, the home address or 0.0.0.0.  Even
      if the HA mistakenly does accept the registration, the mobile node
      will not be able to receive forward tunnelled data if it is behind
      a NAT.

      (It would be beneficial to have the mobile node de-register in
      this case.  The mobile node, however, normally has no way of
      telling that it is behind a NAT if it does not receive a UDP
      Tunnelling Reply.)

   NAT detected by home agent, but traversal not allowed:

      In some cases the home agent may disable NAT traversal even though
      it supports the UDP Tunnel Request extension and a NAT is
      detected.  In this case, the home agent SHOULD send a Registration
      Reply with the Code field set to 129, "administratively
      prohibited".



Levkowetz & Vaarala         Standards Track                    [Page 19]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   NAT not detected, 'F' flag set, but home agent does not allow forced
   use of MIP UDP tunnelling:

      The home agent SHOULD send a Registration Reply with the Code
      field set to 129, "administratively prohibited".

   UDP Tunnel Request extension sent by the mobile node (placed before
   the MN-HA authentication extension), but 'D' bit in registration
   request header not set:

      The home agent SHOULD send a Registration Reply with the Code
      field set to 134, "poorly formed Request".

   UDP Tunnel Request extension sent by the foreign agent (placed after
   the MN-HA authentication extension), but 'D' bit is set:

      The home agent SHOULD send a Registration Reply with the Code
      field set to 134, "poorly formed Request".

   Reserved 3 field of UDP Tunnel Request extension is nonzero:

      The home agent SHOULD send a Registration Reply with the Code
      field set to 134, "poorly formed Request".

   Encapsulation type requested in UDP Tunnel Request extension is
   unsupported:

      The home agent SHOULD send a Registration Reply with the Code
      field set to ERROR_HA_UDP_ENCAP_UNAVAIL, "Requested UDP tunnel
      encapsulation unavailable" defined in Section 3.5.

4.7 MIP signalling versus tunnelling

   UDP tunnelling SHALL be used only for data packets, and only when the
   mobility binding used for sending was established using the UDP
   Tunnel Request, and accepted by an UDP Tunnel Reply from the home
   agent.  After MIP UDP tunnelling has been established for a mobility
   binding, data packets that are forward or reverse tunnelled using
   this mobility binding MUST be tunnelled using MIP UDP tunnelling, not
   IP-in-IP tunnelling or some other tunnelling method.

   As a consequence:

   -  Mobile IP signalling is never tunnelled.

   -  When using simultaneous bindings, each binding may have a
      different type (i.e., UDP tunnelling bindings may be mixed with
      non-UDP tunnelling bindings).



Levkowetz & Vaarala         Standards Track                    [Page 20]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   -  Tunnelling is only allowed for the duration of the binding
      lifetime.

4.8 Packet fragmentation

   From RFC 3022 [12]:

   "Translation of outbound TCP/UDP fragments (i.e., those originating
   from private hosts) in NAPT set-up are doomed to fail.  The reason is
   as follows.  Only the first fragment contains the TCP/UDP header that
   would be necessary to associate the packet to a session for
   translation purposes.  Subsequent fragments do not contain TCP/UDP
   port information, but simply carry the same fragmentation identifier
   specified in the first fragment.  Say, two private hosts originated
   fragmented TCP/UDP packets to the same destination host.  And, they
   happened to use the same fragmentation identifier.  When the target
   host receives the two unrelated datagrams, carrying same
   fragmentation id, and from the same assigned host address, it is
   unable to determine which of the two sessions the datagrams belong
   to.  Consequently, both sessions will be corrupted."

   Because of this, if the mobile node or foreign agent for any reason
   needs to send fragmented packets, the fragmentation MUST be done
   prior to the encapsulation.  This differs from the case for IP-in-IP
   tunnelling, where fragmentation may be done before or after
   encapsulation, although RFC 2003 [4] recommends doing it before
   encapsulation.

   A similar issue exists with some firewalls, which may have rules that
   only permit traffic on certain TCP and UDP ports, and not arbitrary
   outbound (or inbound) IP traffic.  If this is the case and the
   firewall is not set to do packet reassembly, a home agent behind a
   firewall will also have to do packet fragmentation before MIP UDP
   encapsulation.  Otherwise, only the first fragment (which contains
   the UDP header) will be allowed to pass from the home agent out
   through the firewall.

   For this reason, the home agent SHOULD do packet fragmentation before
   it does MIP UDP encapsulation.

4.9 Tunnel Keepalive

   As the existence of the bi-directional UDP tunnel through the NAT is
   dependent on the NAT keeping state information associated with a
   session, as described in RFC 2663 [11], and as the NAT may decide
   that the session has terminated after a certain time, keepalive
   messages may be needed to keep the tunnel open.  The keepalives
   should be sent more often than the timeout value used by the NAT.



Levkowetz & Vaarala         Standards Track                    [Page 21]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   This timeout may be assumed to be a couple of minutes, according to
   RFC 2663 [11], but it is conceivable that shorter timeouts may exist
   in some NATs.

   For this reason the extension used to set up the UDP tunnel has the
   option of setting the keepalive message interval to another value
   than the default value, see Section 3.2.

   The keepalive message sent MUST consist of a properly UDP
   encapsulated ICMP echo request directed to the home agent.

   For each mobility binding which has UDP tunnelling established, the
   non-HA endpoint of the Mobile-IP UDP tunnel MUST send a keepalive
   packet if no other packet to the HA has been sent in K seconds.  Here
   K is a parameter with a default value of 110 seconds.  K may be set
   to another value by the HA as described in the UDP tunnelling reply
   extension (Section 3.2).

   Except for the case where the mobile node registers with a co-located
   address through an FA (see Section 4.11) MIP UDP tunnelling is done
   using the same ports that have already been used for the registration
   request / reply exchange.  The MN or FA will send its first keepalive
   message at the earliest K seconds after the registration request was
   sent.  The same UDP source port MUST be used for the keepalive
   messages as was used for the original Registration Messages and for
   data messages.

   The remote UDP tunnel endpoint MUST use two-way keepalives consisting
   of UDP encapsulated ICMP Echo Request/Reply messages.  The rationale
   for using two-way keepalives is two-fold:

   1. Two-way keepalives allow the mobile node to detect loss of a NAT
      mapping.  Detection of NAT mapping loss in turn allows the MN to
      compensate by re-registering and using a shorter keepalive to
      avoid loss of NAT mappings in the future.

   2. One-way keepalives (keepalives sent by MN or FA, but without any
      reply from the home agent) actually cause more keepalive traffic
      overhead; the keepalive messages have to be sent more frequently
      to compensate for occasional loss of keepalive messages.  In
      contrast, two-way keepalives are acknowledged, and retransmissions
      occur only when a response is not received for a keepalive request
      within a reasonable time.

4.10 Detecting and compensating for loss of NAT mapping

   When a mobile node is using UDP encapsulated ICMP Echo Request/Reply
   messages as keepalives, it will have to deal with the possibility



Levkowetz & Vaarala         Standards Track                    [Page 22]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   that a NAT mapping is lost by a NAT device.  The crucial thing here
   is of course not the loss of the NAT mapping in itself; but rather
   that the home agent, in the absence of a Registration Request through
   the new mapping, will continue to send traffic to the NAT port
   associated with the old mapping.

   If the mobile node does not get a reply to its UDP encapsulated ICMP
   Echo Request even after a number of retransmissions, and is still
   connected to the same router that was used to establish the current
   mobility binding, the mobile node SHOULD re-register with the home
   agent by sending an Registration Request.  This lets the HA know
   about the new NAT mapping and restores connectivity between mobile
   node and home agent.

   Having established a new mobility binding, the mobile node MAY use a
   shorter keepalive interval than before the NAT mapping was lost; in
   particular, the mobile node MAY deviate from the keepalive interval
   assigned by the home agent.  If the binding loss continues to occur,
   the mobile node may shorten the keepalive interval each time it re-
   registers, in order to end up with a keepalive interval that is
   sufficient to keep the NAT mapping alive.  The strategy used to
   arrive at a keepalive interval when a NAT mapping is lost is
   implementation dependent.  However, the mobile node MUST NOT use a
   keepalive less than 10 seconds.

   Note that the above discussion only applies when the mobile node is
   re-registering through the same router, and thus presumably through
   the same NAT device that lost a NAT mapping earlier.  If the MN moves
   and still finds itself behind a NAT, it SHOULD return to its original
   keepalive interval (the default value, or as assigned by the home
   agent) and it SHOULD NOT do any keepalive interval compensation
   unless it discovers a loss of NAT mapping in the new environment.

   The home agent MUST NOT attempt to detect or compensate for NAT
   binding loss by dynamically changing the keepalive interval assigned
   in the Registration Reply; the home agent does not have enough
   information to do this reliably and should thus not do it at all.
   The mobile node is in a much better position to determine when a NAT
   mapping has actually been lost.  Note also that a MN is allowed to
   let a NAT mapping expire if the MN no longer needs connectivity.

   The discussion above does only in a limited sense apply to a foreign
   agent which is situated behind a NAT and using MIP UDP tunnelling.
   In this case, it is a matter of permanently configuring the FA to use
   a keepalive interval which is lower than the NAT mapping lifetime,
   rather than trying to dynamically adapt to the binding lifetimes of
   different NATs.




Levkowetz & Vaarala         Standards Track                    [Page 23]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


4.11 Co-located registration through FA

   This section summarizes the protocol details which have been
   necessary in order to handle and support the case when a mobile node
   registers with a co-located address through a foreign agent, due to
   the FA advertisements having the 'R' bit set.  It gives background
   information, but lists no new requirements.

   When a mobile registers a co-located care-of address through an FA,
   the registration request which reaches the HA will have a different
   care-of address in the registration request compared to the source
   address in the registration request IP-header.  If the registration
   request also contains a UDP Tunnel Request Extension, the HA will
   erroneously set up a UDP tunnel, which will go to the FA instead of
   the MN.  For this reason, as mentioned in Section 4.4, the mobile
   node must not include a UDP Tunnel Request Extension in the
   registration if it is registering a co-located address through an FA
   which does not have the 'U' bit set in its advertisements.

   In order to still be able to use MIP UDP tunnelling in this case,
   foreign agents which are situated behind a NAT are encouraged to send
   advertisements which have the 'U' bit set, as described in Section
   3.4.

   If the FA advertisement has the 'U' bit set, indicating that it is
   behind a NAT, and also the 'R' bit set, and the mobile node wishes to
   use a co-located care-of address, it MUST set the 'R' flag in the UDP
   Tunnel Request Extension, in order to inform the HA of the situation
   so that it may act appropriately, as described in Section 4.4.

   Because the UDP tunnel is now taking another path than the
   registration requests, the home agent, when handling registrations of
   this type, must wait till the arrival of the first keepalive packet
   before it can set up the tunnel to the correct address and port.  To
   reduce the possibility of tunnel hijacking by sending a keepalive
   with a phony source address, it is required that only the port of the
   keepalive packet may be different from that of the registration
   request; the source address must be the same.  This means that if the
   FA and MN are communicating with the HA through different NATs, the
   connection will fail.

5. Implementation Issues

5.1 Movement Detection and Private Address Aliasing

   In providing a mobile node with a mechanism for NAT traversal of
   Mobile IP traffic, we expand the address space where a mobile node
   may function and acquire care-of addresses.  With this comes a new



Levkowetz & Vaarala         Standards Track                    [Page 24]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   problem of movement detection and address aliasing.  We here have a
   case which may not occur frequently, but is mentioned for
   completeness:

   Since private networks use overlapping address spaces, they may be
   mistaken for one another in some situations; this is referred to as
   private address aliasing in this document.  For this reason, it may
   be necessary for mobile nodes implementing this specification to
   monitor the link layer address(es) of the gateway(s) used for sending
   packets.  A change in the link layer address indicates probable
   movement to a new network, even if the IP address remains reachable
   using the new link layer address.

   For instance, a mobile node may obtain the co-located care-of address
   10.0.0.1, netmask 255.0.0.0, and gateway 10.255.255.254 using DHCP
   from network #1.  It then moves to network #2, which uses an
   identical addressing scheme.  The only difference for the mobile node
   is the gateway's link layer address.  The mobile node should store
   the link layer address it initially obtains for the gateway (using
   ARP, for instance).  The mobile node may then detect changes in the
   link layer address in successive ARP exchanges as part of its
   ordinary movement detection mechanism.

   In rare cases the mobile nodes may not be able to monitor the link
   layer address of the gateway(s) it is using, and may thus confuse one
   point of attachment with another.  This specification does not
   explicitly address this issue.  The potential traffic blackout caused
   by this situation may be limited by ensuring that the mobility
   binding lifetime is short enough; the re-registration caused by
   expiration of the mobility binding fixes the problem (see Section
   5.2).

5.2 Mobility Binding Lifetime

   When responding to a registration request with a registration reply,
   the home agent is allowed to decrease the lifetime indicated in the
   registration request, as covered in RFC 3344 [10].  When using UDP
   tunnelling, there are some cases where a short lifetime is
   beneficial.

   First, if the NAT mapping maintained by the NAT device is dropped, a
   connection blackout will arise.  New packets sent by the mobile node
   (or the foreign agent) will establish a new NAT mapping, which the
   home agent will not recognize until a new mobility binding is
   established by a new registration request.

   A second case where a short lifetime is useful is related to the
   aliasing of private network addresses.  In case the mobile node is



Levkowetz & Vaarala         Standards Track                    [Page 25]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   not able to detect mobility and ends up behind a new NAT device (as
   described in Section 5.1), a short lifetime will ensure that the
   traffic blackout will not be exceedingly long, and is terminated by a
   re-registration.

   The definition of "short lifetime" in this context is dependent on
   the requirements of the usage scenario.  Suggested maximum lifetime
   returned by the home agent is 60 seconds, but in case the
   abovementioned scenarios are not considered a problem, longer
   lifetimes may of course be used.

6. Security Considerations

   The ordinary Mobile IP security mechanisms are also used with the NAT
   traversal mechanism described in this document.  However, there is
   one noticeable change: the NAT traversal mechanism requires that the
   HA trust unauthenticated address (and port) fields possibly modified
   by NATs.

   Relying on unauthenticated address information when forming or
   updating a mobility binding leads to several redirection attack
   vulnerabilities.  In essence, an attacker may do what NATs do, i.e.,
   modify addresses and ports and thus cause traffic to be redirected to
   a chosen address.  The same vulnerabilities apply to both MN-HA and
   FA-HA NAT traversal.

   In more detail: without a NAT, the care-of address in the
   registration request will be directly used by the HA to send traffic
   back to the MN (or the FA), and the care-of address is protected by
   the MN-HA (or FA-HA) authentication extension.  When communicating
   across a NAT, the effective care-of address from the HA point of view
   is that of the NAT, which is not protected by any authentication
   extension, but inferred from the apparent IP source address of
   received packets.  This means that by using the mobile IP
   registration extensions described in this document to enable
   traversal of NATs, one is opening oneself up to having the care-of
   address of a MN (or a FA) maliciously changed by an attacker.

   Some, but not all, of the attacks could be alleviated to some extent
   by using a simple routability check.  However, this document does not
   specify such a mechanism for simplicity reasons and because the
   mechanism would not protect against all redirection attacks.  To
   limit the duration of such redirection attacks, it is RECOMMENDED to
   use a conservative (that is, short) mobility binding lifetime when
   using the NAT traversal mechanism specified in this document.

   The known security issues are described in the sections that follow.




Levkowetz & Vaarala         Standards Track                    [Page 26]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


6.1 Traffic Redirection Vulnerabilities

6.1.1 Manipulation of the Registration Request Message

   An attacker on the route between the mobile node (or foreign agent)
   and the home agent may redirect mobility bindings to a desired
   address simply by modifying the IP and UDP headers of the
   Registration Request message.  Having modified the binding, the
   attacker no longer needs to listen to (or manipulate) the traffic.
   The redirection is in force until the mobility binding expires or the
   mobile node re-registers.

   This vulnerability may be used by an attacker to read traffic
   destined to a mobile node, and to send traffic impersonating the
   mobile node.  The vulnerability may also be used to redirect traffic
   to a victim host in order to cause denial-of-service on the victim.

   The only defense against this vulnerability is to have a short time
   between re-registrations, which limits the duration of the
   redirection attack after the attacker has stopped modifying
   registration messages.

6.1.2 Sending a Bogus Keepalive Message

   When registering through an FA using a co-located care-of address,
   another redirection vulnerability opens up.  Having exchanged
   Registration Request/Reply messages with the HA through the FA, the
   MN is expected to send the first keepalive message to the HA, thus
   finalizing the mobility binding (the binding will remain in a "half
   bound" state until the keepalive is received).

   Having observed a Registration Request/Reply exchange, an attacker
   may send a bogus keepalive message assuming that the mobility binding
   is in the "half bound" state.  This opens up a similar redirection
   attack as discussed in Section 6.1.1.  Note, however, that the
   attacker does not need to be able to modify packets in flight; simply
   being able to observe the Registration Request/Reply message exchange
   is sufficient to mount the attack.

   With this in mind, the home agent MUST NOT accept a keepalive message
   from a different source IP address than where the Registration
   Request came from, as specified in Section 4.6.  This requirement
   limits the extent of the attack to redirecting the traffic to a bogus
   UDP port, while the IP address must remain the same as in the initial
   Registration Request.






Levkowetz & Vaarala         Standards Track                    [Page 27]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


   The only defenses against this vulnerability are: (1) to have a short
   time between re-registrations, which limits the duration of the
   redirection attack after the attacker has stopped sending bogus
   keepalive messages, and (2) to minimize the time the binding is in a
   "half bound" state by having the mobile node send the first keepalive
   message immediately after receiving an affirmative registration
   reply.

6.2 Use of IPsec

   If the intermediate network is considered insecure, it is recommended
   that IPsec be used to protect user data traffic.  However, IPsec does
   not protect against the redirection attacks described previously,
   other than to protect confidentiality of hijacked user data traffic.

   The NAT traversal mechanism described in this document allows all
   IPsec-related traffic to go through NATs without any modifications to
   IPsec.  In addition, the IPsec security associations do not need to
   be re-established when the mobile node moves.

6.3 Firewall Considerations

   This document does not specify a general firewall traversal
   mechanism.  However, the mechanism makes it possible to use only a
   single address and a port for all MN-HA (or FA-HA) communication.
   Furthermore, using the same port for the MIP UDP tunnelled traffic as
   for control messages makes it quite probable that if a MIP
   registration can reach the home agent, MIP tunnelling and reverse
   tunnelling using the described mechanism will also work.

7. UNSAF Considerations

   The mechanism described in this document is not an "UNilateral Self-
   Address Fixing" (UNSAF) mechanism.  Although the mobile node makes no
   attempt to determine or use the NAT translated address, the mobile
   node through the registration process does attempt to keep the NAT
   mapping alive through refresh messages.  This section attempts to
   address issues that may be raised through this usage through the
   framework of the unsaf considerations IAB document [13].

   1. Precise definition.
      This proposal extends the Mobile IP v4 registration process to
      work across intervening NATs.  The Home Agent detects the presence
      of the NAT by examining the source address in the packet header
      and comparing it with the address contained in the registration
      message.





Levkowetz & Vaarala         Standards Track                    [Page 28]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


      The NAT address and port detected by the home agent are not
      exported or communicated to any other node anywhere.

   2. Exit strategy.
      This mechanism will go out of use as IPv6 and Mobile IP v6 is
      deployed, obviating the need for MIPv4 NAT traversal.

      It can also be noted that this mechanism makes no changes to the
      base MIPv4 protocol which makes it dependent on the presence of
      NATs or the current extensions - i.e., no additional protocol
      changes would be needed if NATs were to go away.

   3. Issues making systems more brittle.
      The specific issue which is relevant here is that the effective
      care-of address (being the source address in the IP header
      received by the HA) is not protected by the Mobile IP
      authentication extension, and therefore may be spoofed.  This is
      discussed in some detail in Section 6, Security Considerations.

   4. Requirements for longer term solutions.
      The trivial long term solution is a transition to an environment
      where NATs are not required.  The most obvious such environment
      would be an IPv6 based internet.

      In the presence of NATs, an improved solution would require

      *  the ability to discover the translations done by each NAT along
         the route

      *  the ability to validate the authority of each NAT to do those
         translations

      *  communicating as part of the signed registration request the
         address of the NAT closest to the HA, for use as the effective
         care-of address from the viewpoint of the HA.

      *  configuration of all intermediate NATs to accept only packets
         from the neighbour NATs.

   5. Impact on existing, deployed NATs.
      One precursor of the mechanism described here has been used
      successfully across deployed NATs in Sweden, Germany, England,
      Japan and the USA, without necessitating neither adjustments of
      the NATs in question, nor adjustment of any protocol parameters.
      At the time of writing, little experience exist with the exact
      implementation proposed in this document, but effort has been put
      into making this mechanism even more robust and adaptive than its
      precursors.



Levkowetz & Vaarala         Standards Track                    [Page 29]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


      With respect to the base Mobile IP specification, the impact of
      this document is that an increased frequency of registration
      requests is recommended from a security perspective when the NAT
      traversal mechanism is used.

8. IANA Considerations

   The numbers for the extensions defined in this document have been
   taken from the numbering space defined for Mobile IP messages,
   registration extensions and error codes defined in RFC 3344 [10].
   This document proposes one new message, two new extensions and a new
   error code that require type numbers and an error code value that
   have been assigned by IANA.  The two new extensions also introduce
   two new sub-type numbering spaces to be managed by IANA.

   Section 3.1 defines a new Mobile IP extension, the UDP Tunnel Request
   Extension.  The type number for this extension is 144.  This
   extension introduces a new sub-type numbering space where the value 0
   has been assigned to this extension.  Approval of new Tunnel Request
   Extension sub-type numbers is subject to Expert Review, and a
   specification is required [7].

   Section 3.2 defines a new Mobile IP extension, the UDP Tunnel Reply
   Extension.  The type value for this extension is 44.  This extension
   introduces a new sub-type numbering space where the value 0 has been
   assigned to this extension.  Approval of new Tunnel Reply Extension
   sub-type numbers is subject to Expert Review, and a specification is
   required [7].

   Section 3.3 defines a new Mobile IP message, the Tunnel Data message.
   The type value for this message is 4.

   Section 3.5 defines a new error code, ERROR_HA_UDP_ENCAP_UNAVAIL:
   "Requested UDP tunnel encapsulation unavailable", from the numbering
   space for values defined for use with the Code field of Mobile IP
   Registration Reply Messages.  Code number 142 has been assigned from
   the subset "Error Codes from the Home Agent".

   The values for the Next Header field in the MIP Tunnel Data Message
   (Section 3.3) shall be the same as those used for the Protocol field
   of the IP header [2], and requires no new number assignment.

9. Intellectual Property Rights

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this
   document.  For more information consult the online list of claimed
   rights (www.ietf.org/ipr.html).



Levkowetz & Vaarala         Standards Track                    [Page 30]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


10. Acknowledgements

   Much of the text in Section 4.2 has been taken almost verbatim from
   RFC 2003, IP Encapsulation within IP [4].

   Adding support for the FA case was suggested by George Tsirtsis and
   Frode B. Nilsen.  Roy Jose pointed out a problem with binding
   updates, and Frode, Roy and George pointed out that there are cases
   where triangular routes may work, and suggested that reverse
   tunnelling need not be mandatory.  Roy and Qiang Zhang drew attention
   to a number of sections which needed to be corrected or stated more
   clearly.

   Phil Roberts helped remove a number of rough edges.  Farid Adrangi
   pointed out the DoS issue now covered in Security Considerations
   (Section 6).  Francis Dupont's helpful comments made us extend the
   Security Considerations section to make it more comprehensive and
   clear.  Milind Kulkarni and Madhavi Chandra pointed out the required
   match between the FA source and care-of addresses when the mechanism
   is used by an FA, and also contributed a number of clarifications to
   the text.

   Thanks also to our co-workers, Ilkka Pietikainen, Antti Nuopponen and
   Timo Aalto at Netseal and Hans Sjostrand, Fredrik Johansson and Erik
   Liden at ipUnplugged.  They have read and re-read the text, and
   contributed many valuable corrections and insights.

11. Normative References

   [1]  Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
        1980.

   [2]  Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

   [3]  Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing
        Encapsulation (GRE)", RFC 1701, October 1994.

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

   [5]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
        October 1996.

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

   [7]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.



Levkowetz & Vaarala         Standards Track                    [Page 31]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


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

   [9]  Montenegro, G., "Reverse Tunneling for Mobile IP, revised", RFC
        3024, January 2001.

   [10] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
        2002.

12. Informative References

   [11] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
        (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [12] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
        Translator (Traditional NAT)", RFC 3022, January 2001.

   [13] Daigle, L., Editor, and IAB, "IAB Considerations for UNilateral
        Self-Address Fixing (UNSAF)", RFC 3424, November 2002.
































Levkowetz & Vaarala         Standards Track                    [Page 32]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


13. Authors' Addresses

   Henrik Levkowetz
   ipUnplugged AB
   Arenavagen 23
   Stockholm  S-121 28
   SWEDEN

   Phone: +46 708 32 16 08
   EMail: henrik@levkowetz.com


   Sami Vaarala
   Netseal
   Niittykatu 6
   Espoo  02201
   FINLAND

   Phone: +358 9 435 310
   EMail: sami.vaarala@iki.fi































Levkowetz & Vaarala         Standards Track                    [Page 33]
^L
RFC 3519              NAT Traversal for Mobile IP             April 2003


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.



















Levkowetz & Vaarala         Standards Track                    [Page 34]
^L