File: rfc6748.html

package info (click to toggle)
doc-rfc 20201128-1
  • links: PTS, VCS
  • area: non-free
  • in suites: bullseye
  • size: 1,307,124 kB
file content (2069 lines) | stat: -rw-r--r-- 109,227 bytes parent folder | download | duplicates (2)
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
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
<pre>Internet Research Task Force (IRTF)                          RJ Atkinson
Request for Comments: 6748                                    Consultant
Category: Experimental                                         SN Bhatti
ISSN: 2070-1721                                            U. St Andrews
                                                           November 2012


             <span class="h1">Optional Advanced Deployment Scenarios for the</span>
               <span class="h1">Identifier-Locator Network Protocol (ILNP)</span>

Abstract

   This document provides an Architectural description and the Concept
   of Operations of some optional advanced deployment scenarios for the
   Identifier-Locator Network Protocol (ILNP), which is an evolutionary
   enhancement to IP.  None of the functions described here is required
   for the use or deployment of ILNP.  Instead, it offers descriptions
   of engineering and deployment options that might provide either
   enhanced capability or convenience in administration or management of
   ILNP-based systems.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

   This document defines an Experimental Protocol for the Internet
   community.  This document is a product of the Internet Research Task
   Force (IRTF).  The IRTF publishes the results of Internet-related
   research and development activities.  These results might not be
   suitable for deployment.  This RFC represents the individual
   opinion(s) of one or more members of the Routing Research Group of
   the Internet Research Task Force (IRTF).  Documents approved for
   publication by the IRSG are not a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6748">http://www.rfc-editor.org/info/rfc6748</a>.











<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   This document may not be modified, and derivative works of it may not
   be created, except to format it for publication as an RFC or to
   translate it into languages other than English.




































<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-4">4</a>
      <a href="#section-1.1">1.1</a>. Document Roadmap ...........................................<a href="#page-5">5</a>
      <a href="#section-1.2">1.2</a>. Terminology ................................................<a href="#page-6">6</a>
   <a href="#section-2">2</a>. Localised Numbering .............................................<a href="#page-6">6</a>
      <a href="#section-2.1">2.1</a>. Localised Locators .........................................<a href="#page-7">7</a>
      <a href="#section-2.2">2.2</a>. Mixed Local/Global Numbering ...............................<a href="#page-9">9</a>
      <a href="#section-2.3">2.3</a>. Dealing with Internal Subnets with Locator Rewriting .......<a href="#page-9">9</a>
      <a href="#section-2.4">2.4</a>. Localised Name Resolution with DNS ........................<a href="#page-11">11</a>
      <a href="#section-2.5">2.5</a>. Use of mDNS ...............................................<a href="#page-13">13</a>
      <a href="#section-2.6">2.6</a>. Site Network Name in DNS ..................................<a href="#page-13">13</a>
      <a href="#section-2.7">2.7</a>. Site Interior Topology Obfuscation ........................<a href="#page-14">14</a>
      <a href="#section-2.8">2.8</a>. Other SBR Considerations ..................................<a href="#page-14">14</a>
   <a href="#section-3">3</a>. An Alternative for Site Multihoming ............................<a href="#page-16">16</a>
      <a href="#section-3.1">3.1</a>. Site Multihoming (S-MH) Connectivity Using an SBR .........<a href="#page-16">16</a>
      <a href="#section-3.2">3.2</a>. Dealing with Link/Connectivity Changes ....................<a href="#page-17">17</a>
      <a href="#section-3.3">3.3</a>. SBR Updates to DNS ........................................<a href="#page-18">18</a>
      <a href="#section-3.4">3.4</a>. DNS TTL Values for L32 and L64 Records ....................<a href="#page-18">18</a>
      <a href="#section-3.5">3.5</a>. Multiple SBRs .............................................<a href="#page-19">19</a>
   <a href="#section-4">4</a>. An Alternative for Site (Network) Mobility .....................<a href="#page-20">20</a>
      <a href="#section-4.1">4.1</a>. Site (Network) Mobility ...................................<a href="#page-20">20</a>
      <a href="#section-4.2">4.2</a>. SBR Updates to DNS ........................................<a href="#page-22">22</a>
      <a href="#section-4.3">4.3</a>. DNS TTL Values for L32 and L64 Records ....................<a href="#page-22">22</a>
   <a href="#section-5">5</a>. Traffic Engineering Options ....................................<a href="#page-22">22</a>
      <a href="#section-5.1">5.1</a>. Load Balancing ............................................<a href="#page-23">23</a>
      <a href="#section-5.2">5.2</a>. Control of Egress Traffic Paths ...........................<a href="#page-24">24</a>
   <a href="#section-6">6</a>. ILNP in Datacentres ............................................<a href="#page-26">26</a>
      <a href="#section-6.1">6.1</a>. Virtual Image Mobility within a Single Datacentre .........<a href="#page-27">27</a>
      <a href="#section-6.2">6.2</a>. Virtual Image Mobility between Datacentres - Invisible ....<a href="#page-28">28</a>
      <a href="#section-6.3">6.3</a>. Virtual Image Mobility between Datacentres - Visible ......<a href="#page-29">29</a>
      <a href="#section-6.4">6.4</a>. ILNP Capability in the Remote Host for VM Image Mobility ..29
   <a href="#section-7">7</a>. Location Privacy ...............................................<a href="#page-30">30</a>
      <a href="#section-7.1">7.1</a>. Locator Rewriting Relay (LRR) .............................<a href="#page-30">30</a>
      <a href="#section-7.2">7.2</a>. Options for Installing LRR Packet Forwarding State ........<a href="#page-31">31</a>
   <a href="#section-8">8</a>. Identity Privacy ...............................................<a href="#page-32">32</a>
   <a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-32">32</a>
   <a href="#section-10">10</a>. References ....................................................<a href="#page-33">33</a>
      <a href="#section-10.1">10.1</a>. Normative References .....................................<a href="#page-33">33</a>
      <a href="#section-10.2">10.2</a>. Informative References ...................................<a href="#page-34">34</a>
   <a href="#section-11">11</a>. Acknowledgements ..............................................<a href="#page-37">37</a>










<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document is part of the ILNP document set, which has had
   extensive review within the IRTF Routing RG.  ILNP is one of the
   recommendations made by the RG Chairs.  Separately, various refereed
   research papers on ILNP have also been published during this decade.
   So, the ideas contained herein have had much broader review than the
   IRTF Routing RG.  The views in this document were considered
   controversial by the Routing RG, but the RG reached a consensus that
   the document still should be published.  The Routing RG has had
   remarkably little consensus on anything, so virtually all Routing RG
   outputs are considered controversial.

   At present, the Internet research and development community is
   exploring various approaches to evolving the Internet Architecture to
   solve a variety of issues including, but not limited to, scalability
   of inter-domain routing [<a href="./rfc4984" title="&quot;Report from the IAB Workshop on Routing and Addressing&quot;">RFC4984</a>].  A wide range of other issues
   (e.g., site multihoming, node multihoming, site/subnet mobility, node
   mobility) are also active concerns at present.  Several different
   classes of evolution are being considered by the Internet research
   and development community.  One class is often called "Map and
   Encapsulate", where traffic would be mapped and then tunnelled
   through the inter-domain core of the Internet.  Another class being
   considered is sometimes known as "Identifier/Locator Split".  This
   document relates to a proposal that is in the latter class of
   evolutionary approaches.

   ILNP is, in essence, an end-to-end architecture: the functions
   required for ILNP are implemented in, and controlled by, only those
   end-systems that wish to use ILNP, as described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>].  Other
   nodes, such as Site Border Routers (SBRs) need only support IP to
   allow operation of ILNP, e.g., an SBR should support IPv6 in order to
   enable end-systems to operate ILNPv6 within the site network for
   which an SBR provides a service [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].

   However, some features of ILNP could be optimised, from an
   engineering perspective, by the use of an intermediate system (a
   router, security gateway or "middlebox") that modifies (rewrites)
   Locator values of transit ILNP packets.  It would also perform other
   control functions for an entire site, as an administrative
   convenience, such as providing a centralised point of management for
   a site.  For example, an SBR might manipulate the topological
   presence of the packet, providing an elegant solution to the
   provision of functions such as site (network) mobility for an entire
   end site [<a href="#ref-ABH09a" title="&quot;Site- Controlled Secure Multi-Homing and Traffic Engineering For IP&quot;">ABH09a</a>].






<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   This document discusses several such optional advanced deployment
   scenarios for ILNP.  These typically use an ILNP-capable Site Border
   Router (SBR).

   Nothing in this document is a requirement for any ILNP implementation
   or any ILNP deployment.

   Readers are strongly advised to first read the ILNP Architecture
   Description [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], as this document uses the notation and
   terminology described or referenced in that document.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Document Roadmap</span>

   This document describes engineering and implementation considerations
   that are common to ILNP for both IPv4 and IPv6.

   The ILNP architecture can have more than one engineering
   instantiation.  For example, one can imagine a "clean-slate"
   engineering design based on the ILNP architecture.  In separate
   documents, we describe two specific engineering instances of ILNP.
   The term "ILNPv6" refers precisely to an instance of ILNP that is
   based upon, and backwards compatible with, IPv6.  The term "ILNPv4"
   refers precisely to an instance of ILNP that is based upon, and
   backwards compatible with, IPv4.

   Many engineering aspects common to both ILNPv4 and ILNPv6 are
   described in [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].  A full engineering specification for either
   ILNPv6 or ILNPv4 is beyond the scope of this document.

   Readers are referred to other related ILNP documents for details not
   described here:

   a) [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>] is the main architectural description of ILNP, including
      the concept of operations.

   b) [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>] describes engineering and implementation considerations
      that are common to both ILNPv4 and ILNPv6.

   c) [<a href="./rfc6742" title="&quot;DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)&quot;">RFC6742</a>] defines additional DNS resource records that support
      ILNP.

   d) [<a href="./rfc6743" title="&quot;ICMPv6 Locator Update Message&quot;">RFC6743</a>] defines a new ICMPv6 Locator Update message used by an
      ILNP node to inform its correspondent nodes of any changes to its
      set of valid Locators.







<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   e) [<a href="./rfc6744" title="&quot;IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)&quot;">RFC6744</a>] defines a new IPv6 Nonce Destination Option used by
      ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by
      inclusion within the initial packets of an ILNP session) that the
      node is operating in the ILNP mode and (2) to prevent off-path
      attacks against ILNP ICMP messages.  This Nonce is used, for
      example, with all ILNP ICMPv6 Locator Update messages that are
      exchanged among ILNP correspondent nodes.

   f) [<a href="./rfc6745" title="&quot;ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)&quot;">RFC6745</a>] defines a new ICMPv4 Locator Update message used by an
      ILNP node to inform its correspondent nodes of any changes to its
      set of valid Locators.

   g) [<a href="./rfc6746" title="&quot;IPv4 Options for the Identifier-Locator Network Protocol (ILNP)&quot;">RFC6746</a>] defines a new IPv4 Nonce Option used by ILNPv4 nodes to
      carry a security nonce to prevent off-path attacks against ILNP
      ICMP messages and also defines a new IPv4 Identifier Option used
      by ILNPv4 nodes.

   h) [<a href="./rfc6747" title="&quot;Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)&quot;">RFC6747</a>] describes extensions to Address Resolution Protocol
      (ARP) for use with ILNPv4.

<span class="h3"><a class="selflink" id="section-1.2" href="#section-1.2">1.2</a>.  Terminology</span>

   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 [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Localised Numbering</span>

   Today, Network Address Translation (NAT) [<a href="./rfc3022" title="&quot;Traditional IP Network Address Translator (Traditional NAT)&quot;">RFC3022</a>] is used for a
   number of purposes.  Whilst one of the original intentions of NAT was
   to reduce the rate of use of global IPv4 addresses, through use of
   IPv4 private address space [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>], NAT also offers to site
   administrators a convenient localised address management capability
   combined with a local-scope/private address space, for example,
   [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>] for IPv4.

   For IPv6, NAT would not necessarily be required to reduce the rate of
   IPv6 address depletion, because the availability of addresses is not
   such an issue as for IPv4.  The IETF has standardised Unique Local
   IPv6 Unicast Addresses [<a href="./rfc4193" title="&quot;Unique Local IPv6 Unicast Addresses&quot;">RFC4193</a>], which provide local-scope IPv6
   unicast address space that can be used by end sites.  However,
   localised address management, in a manner similar to that provided by









<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   IPv4 NAT and private address space [<a href="./rfc1918" title="&quot;Address Allocation for Private Internets&quot;">RFC1918</a>], is still desirable for
   IPv6 [<a href="./rfc5902" title="&quot;IAB Thoughts on IPv6 Network Address Translation&quot;">RFC5902</a>], even though there is debate about the efficacy of
   such an approach [<a href="./rfc4864" title="&quot;Local Network Protection for IPv6&quot;">RFC4864</a>].

   One of the major concerns that many have had with NAT is the loss of
   end-to-end transport-layer and network-layer session state
   invariance, which is still considered an important architectural
   principle by the IAB [<a href="./rfc4924" title="&quot;Reflections on Internet Transparency&quot;">RFC4924</a>].  Nevertheless, the use of localised
   addressing remains in wide use and there is interest in its continued
   use in IPv6, e.g., proposals such as [<a href="./rfc6296" title="&quot;IPv6-to-IPv6 Network Prefix Translation&quot;">RFC6296</a>].

   It is possible to have the benefits of NAT-like functions for ILNP
   without losing end-to-end state.  Indeed, such a mechanism -- the use
   of Locator rewriting in ILNP -- forms the basis of many of the
   optional functions described in this document.  In ILNP, we call this
   feature "localised numbering".

   Recall, that a Locator value in ILNP has the same semantics as a
   routing prefix in IP: indeed, in ILNPv4 and ILNPv6 [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>], routing
   prefixes from IPv4 and IPv6, respectively, are used as Locator
   values.

   We note that a deployment using private/local numbering can also
   provide a convenient solution to centralised management of site
   multihoming and network mobility by deploying SBRs in this manner --
   this is described below.

   Please note that with this proposal, localised numbering (e.g., using
   the equivalent of IP NAT on the ILNP Locator bits) would work in
   harmony with multihoming, mobility (for individual hosts and whole
   networks), and IP Security (IPsec), plus the other advanced functions
   described in this document [<a href="#ref-BA11" title="&quot;Reducing DNS Caching&quot;">BA11</a>] [<a href="#ref-LABH06" title="&quot;A Proposal for Coalition Networking in Dynamic Operational Environments&quot;">LABH06</a>] [<a href="#ref-ABH07a" title="&quot;Mobility as an Integrated Service Through the Use of Naming&quot;">ABH07a</a>] [<a href="#ref-ABH07b" title="&quot;A Proposal for Unifying Mobility with Multi-Homing, NAT, &amp; Security&quot;">ABH07b</a>] [<a href="#ref-ABH08a" title="&quot;Mobility Through Naming: Impact on DNS&quot;">ABH08a</a>]
   [<a href="#ref-ABH08b" title="&quot;Harmonised Resilience, Security, and Mobility Capability for IP&quot;">ABH08b</a>] [<a href="#ref-ABH09a" title="&quot;Site- Controlled Secure Multi-Homing and Traffic Engineering For IP&quot;">ABH09a</a>] [<a href="#ref-ABH09b" title="&quot;ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming&quot;">ABH09b</a>] [<a href="#ref-RAB09" title="&quot;Enabling Mobile Networks Through Secure Naming&quot;">RAB09</a>] [<a href="#ref-RB10" title="&quot;A Comparative Assessment of Routing for Mobile Networks&quot;">RB10</a>] [<a href="#ref-ABH10" title="&quot;Evolving the Internet Architecture Through Naming&quot;">ABH10</a>] [<a href="#ref-BAK11" title="&quot;Integrating Challenged Networks&quot;">BAK11</a>].

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Localised Locators</span>

   For ILNP, the NAT-like function can best be descried by using a
   simple example, based on Figure 2.1.













<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


          site                         . . . .      +----+
         network        SBR           .       .-----+ CN |
         . . . .      +------+ L_1   .         .    +----+
        .       .     |      +------.           .
       .         .L_L |      |      .           .
       .         .----+      |      . Internet  .
       .  H      .    |      |      .           .
        .       .     |      |      .           .
         . . . .      +------+       .         .
                                      .       .
                                       . . . .

            CN = Correspondent Node
             H = Host
           L_1 = global Locator value
           L_L = local Locator value
           SBR = Site Border Router

   Figure 2.1: A Simple Localised Numbering Example for ILNP

   In this scenario, the SBR is allocated global locator value L_1 from
   the upstream provider.  However, the SBR advertises internally a
   "local" Locator value L_L.  By "local" we mean that the Locator value
   only has significance within the site network, and any packets that
   have L_L as a source Locator cannot be forwarded beyond the SBR with
   value L_L as the source Locator.  In engineering terms, L_L would,
   for example, in ILNPv6, be an IPv6 prefix based on the assignments
   possible according to IPv6 Unique Local Addresses (ULAs) [<a href="./rfc4193" title="&quot;Unique Local IPv6 Unicast Addresses&quot;">RFC4193</a>].

   If we assume that H uses Identifier I_H, then it will use Identifier-
   Locator Vector (I-LV) [I_H, L_L], and that the correspondent node
   (CN) uses IL-V [I_CN, L_CN].  If we consider that H will send a UDP
   packet from its port P_H to CN's port P_CN, then H could send a
   UDP/ILNP packet with the tuple expression:

     &lt;UDP: I_H, I_CN, P_H, P_CN&gt;&lt;ILNP: L_L, L_CN&gt;           --- (1a)

   When this packet reaches the SBR, it knows that L_L is a local
   Locator value and so rewrites the source Locator on the egress packet
   to L_1 and forwards that out onto its external-facing interface.  The
   value L_1 is a global prefix, which allows the packet to be routed
   globally:

     &lt;UDP: I_H, I_CN, P_H, P_CN&gt;&lt;ILNP: L_1, L_CN&gt;           --- (1b)

   This packet reaches CN using normal routing based on the Locator
   value L_1, as it is a routing prefix.




<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Note that from expressions (1a) and (1b), the end-to-end state (in
   the UDP tuple) remains unchanged -- end-to-end state invariance is
   honoured, for UDP.  CN would send a UDP packet to H as:

     &lt;UDP: I_CN, I_H, P_CN, P_H&gt;&lt;ILNP: L_CN, L_1&gt;           --- (2a)

   and the SBR would rewrite the Locator value on the ingress packet
   before forwarding the packet on its internal interface:

     &lt;UDP: I_CN, I_H, P_CN, P_H&gt;&lt;ILNP: L_CN, L_L&gt;           --- (2b)

   Again, this preserves the end-to-end transport-layer session state
   invariance.

   As the Locator values are not used in the transport-layer pseudo-
   header for ILNP [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>], the checksum would not have to be
   rewritten.  That is, the Locator rewriting function is stateless and
   has low overhead.

   (A discussion on the generation of Identifier values for initial use
   is presented in [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].)

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Mixed Local/Global Numbering</span>

   It is possible for the SBR to advertise both L_1 and L_L within the
   site, and for hosts within the site to have IL-Vs using both L_1 and
   L_L.  For example, host H may have IL-Vs [I_H, L_1] and [I_H, L_L].
   The configuration and use of such a mechanism can be controlled
   through local policy.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Dealing with Internal Subnets with Locator Rewriting</span>

   Where the site network uses subnets, packets will need to be routed
   correctly, internally.  That is, the site network may have several
   internal Locator values, e.g., L_La, L_Lb, and L_Lc.  When an ingress
   packet has I-LV [I_H, L_1], it is expected that the SBR is capable of
   identifying the correct internal network for I_H, and so the correct
   Locator value to rewrite for the ingress packet.  This is not obvious
   as the I value and the L value are not related in any way.

   There are numerous ways the SBR could facilitate the correct lookup
   of the internal Locator value.  This document does not prescribe any
   specific method.  Of course, we do not preclude mappings directly
   from Identifier values to internal Locator values.

   Of course, such a "flat" mapping (between Identifier values and
   Locators) would serve, but maintaining such a mapping would be
   impractical for a large site.  So, we propose the following solution.



<span class="grey">Atkinson &amp; Bhatti             Experimental                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Consider that the Locator value, L_x consists of two parts, L_pp and
   L_ss, where L_pp is a network prefix and L_ss is a subnet selector.
   Also, consider that this structure is true for both the local
   identifier, L_L, as well as the global Identifier, L_1.  Then, an SBR
   need only know the mapping from the values of L_ss as visible in L_1
   and the values of L_ss used locally.

   Such a mapping could be mechanical, e.g., the L_ss part of L_L and
   L_1 are the same and it is only the L_pp part that is different.
   Where this is not desirable (e.g., for obfuscation of interior
   topology), an administrator would need to configure a suitable
   mapping policy in the SBR, which could be realised as a simple lookup
   table.  Note that with such a policy, the L_pp for L_L and L_1 do not
   need to be of the same size.

   From a practical perspective, this is possible for both ILNPv6
   [<a href="./rfc6177" title="&quot;IPv6 Address Assignment to End Sites&quot;">RFC6177</a>] and ILNPv4 [<a href="./rfc4632" title="&quot;Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan&quot;">RFC4632</a>].  For ILNPv6, recall that the Locator
   value is encoded to be syntactically similar to an IPv6 address
   prefix, as shown in Figure 2.2, taken from [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].

   /* IPv6 */
   | 3 |     45 bits         |  16 bits  |     64 bits             |
   +---+---------------------+-----------+-------------------------+
   |001|global routing prefix| subnet ID |  Interface Identifier   |
   +---+---------------------+-----------+-------------------------+
   /* ILNPv6 */
   |             64 bits                 |     64 bits             |
   +---+---------------------+-----------+-------------------------+
   |          Locator (L64)              |  Node Identifier (NID)  |
   +---+---------------------+-----------+-------------------------+
   +&lt;-------- L_pp ---------&gt;+&lt;- L_ss --&gt;+

     L_pp = Locator prefix part (assigned IPv6 prefix)
     L_ss = Locator subnet selector (locally managed subnet ID)

   Figure 2.2: IPv6 Address format [<a href="./rfc3587">RFC3587</a>] as used in ILNPv6, showing
   how subnets can be identified.

   Note that the subnet ID forms part of the Locator value.  Note also
   that [<a href="./rfc6177" title="&quot;IPv6 Address Assignment to End Sites&quot;">RFC6177</a>] allows the global routing prefix to be more than 45
   bits, and for the subnet ID to be smaller, but still preserving the
   64-bit size of the Locator overall.

   For ILNPv4, the L_pp value overall is an IPv4 routing prefix, which
   is typically less than 32 bits.  However, the ILNPv4 Locator value is
   carried in the 32-bit IP Address space, so the bits not used for the





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   routing prefix could be used for L_ss, e.g., for a /24 IPv4 prefix,
   the situation would be as shown in Figure 2.3, and L_ss could use any
   of the remaining 8-bits as required.

              24 bits           8 bits
     +------------------------+----------+
     |         Locator (L32)             |
     +------------------------+----------+
     +&lt;------- L_pp ---------&gt;+&lt;- L_ss -&gt;+

     L_pp = Locator prefix (assigned IPv4 prefix)
     L_ss = Locator subnet selector (locally managed subnet ID)

   Figure 2.3: IPv4 address format for /24 IPv4 prefix, as used in
   ILNPv4, showing how subnets can be identified.

   As an example, for the case where the interior topology is not
   obfuscated, an interior "engineering" node might have an LP record
   pointing to eng.example.com and eng.example.com might have L32/L64
   records for a specific subnet inside the site.  Meanwhile, an
   interior "operations" node might have an LP record pointing at
   "ops.example.com" that might have different L32/L64 records for that
   specific subnet within the site.  That is, eng.example.com might have
   Locator value L_pp_1:L_ss_1 and ops.example.com might have Locator
   value L_pp_1:L_ss_2.  However, just as for IPv6 or IPv4 routing
   today, the routing for the site would only need to use L_pp_1, which
   is a routing prefix in either IPv6 (for ILNPv6) or IPv4 (for ILNPv4).

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Localised Name Resolution with DNS</span>

   To support private numbering with IPv4 and IPv6 today, some sites use
   a split-horizon DNS service for the site [<a href="#ref-appDNS" title="&quot;Architectural Considerations on Application Features in the DNS&quot;">appDNS</a>].

   If a site using localised numbering chooses to deploy a split-horizon
   DNS server, then the DNS server would return the global-scope
   Locator(s) (L_1 in our example above) of the SBR to DNS clients
   outside the site, and would advertise the local-scope Locator(s) (L_L
   in our example above) specific to that internal node to DNS clients
   inside the site.  Such deployments of split-horizon DNS servers are
   not unusual in the IPv4 Internet today.  If an internal node (e.g.,
   portable computer) moves outside the site, it would follow the normal
   ILNP methods to update its authoritative DNS server with its current
   Locator set.  In this deployment model, the authoritative DNS server
   for that mobile device will be either the split-horizon DNS server
   itself or the master DNS server providing data to the split-horizon
   DNS server.





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   If a site using localised numbering chooses not to deploy a split-
   horizon DNS server, then each internal node would advertise the
   global-scope Locator(s) of the site border routers in its respective
   DNS entries.  To deliver packets from one internal node to another
   internal node, the site would choose to use either Layer 2 bridging
   (e.g., IEEE Spanning Tree or IEEE Rapid Spanning Tree [<a href="#ref-IEEE04" title="&quot;IEEE 802.1D - IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Bridges&quot;">IEEE04</a>], or a
   link-state Layer 2 algorithm such as the IETF TRILL group or IEEE
   802.1 are developing), or the interior routers would forward packets
   up to the nearest site border router, which in turn would then
   rewrite the Locators to appropriate local-scope values, and forward
   the packet towards the interior destination node.

   Alternately, for sites using localised numbering but not deploying a
   split-horizon DNS server, the DNS server could return all global-
   scope and local-scope Locators to all queriers, and assume that nodes
   would use normal, local address/route selection criteria to choose
   the best Locator to use to reach a given remote node ([<a href="./rfc3484" title="&quot;Default Address Selection for Internet Protocol version 6 (IPv6)&quot;">RFC3484</a>] for
   older IPv6 nodes, [<a href="./rfc6724">RFC6724</a>] for newer IPv6 nodes).  Hosts within the
   same site as the correspondent node would only have a ULA configured;
   hence, they would select the ULA destination Locator for the
   correspondent (L_L in our example).  Hosts outside the site would not
   have the same ULA configured (L_CN for the CN in our example).

   However, ILNP allows use of Locator Preference values [<a href="./rfc6742" title="&quot;DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)&quot;">RFC6742</a>]
   [<a href="./rfc6743" title="&quot;ICMPv6 Locator Update Message&quot;">RFC6743</a>].  These values would indicate explicitly the relative
   preference value given to Locator values and so result in the
   selection of the appropriate Locator (and therefore interface) to use
   for the transmission of an outgoing packet with respect to the value
   to be inserted into the IPv6 Source Address field (see <a href="./rfc6741#section-3">Section&nbsp;3 of
   [RFC6741]</a>).  A similar argument, with respect to use of Locator
   preference values, applies to the value to be inserted into the IPv6
   Destination Address field.  Certainly, by using appropriate
   Preference values for a host with multiple Locator values, it would
   be possible to emulate some level of resemblance to the address
   selection rules in [<a href="./rfc3484" title="&quot;Default Address Selection for Internet Protocol version 6 (IPv6)&quot;">RFC3484</a>] and [<a href="./rfc6724">RFC6724</a>], and this could be
   controlled via DNS entries for ILNP nodes, for example.

   Indeed, with appropriate use of localised or site-wide policy, and
   appropriate mechanisms in the devices (e.g. in end hosts operating
   systems or in Site Border Routers), Preference values for Locator
   values within the DNS could be used for allowing options for multi-
   homed transport sessions and/or site-controlled traffic engineering
   [<a href="#ref-ABH09a" title="&quot;Site- Controlled Secure Multi-Homing and Traffic Engineering For IP&quot;">ABH09a</a>].  However, the details for this are left for further study,
   and overall, the rules defined in [<a href="./rfc3484" title="&quot;Default Address Selection for Internet Protocol version 6 (IPv6)&quot;">RFC3484</a>] and [<a href="./rfc6724">RFC6724</a>] cannot be
   applied directly to ILNPv6 nodes.






<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Note that for split-horizon operation, there needs to be a DNS
   management policy for mobile hosts, as when such hosts are away from
   their "home" network, they will need to update DNS entries so that
   the global-scope Locator(s) only is (are) used, and these are
   consistent with the current topological position of the mobile host.
   Such updates would need to be done using Secure Dynamic DNS Update.

   For an ILNP mobile network using LP records, there are likely to
   separate LP records for internal and external use.

<span class="h3"><a class="selflink" id="section-2.5" href="#section-2.5">2.5</a>.  Use of mDNS</span>

   Multicast DNS (mDNS) [<a href="#ref-mDNS11" title="&quot;Multicast DNS&quot;">mDNS11</a>] is popularly used in many end-system
   OSs today, especially desktop OSs (such as Windows, Mac OS X and
   Linux).  It is used for localised name resolution using names with a
   ".local" suffix, for both IPv4 and IPv6.  This protocol would need to
   be modified so that when an ILNP-capable node advertises its ".local"
   name, another ILNP-capable node would be able to see that it is an
   ILNP-capable, but other, non-ILNP nodes would not be perturbed in
   operation.  The details of a mechanism for using mDNS to enable such
   a feature are not defined here.

<span class="h3"><a class="selflink" id="section-2.6" href="#section-2.6">2.6</a>.  Site Network Name in DNS</span>

   In this scenario, if H expects incoming ILNP session requests, for
   example, then remote nodes normally will need to look up appropriate
   Identifier and Locator information in the DNS.  Just as for IP, and
   as already described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], a Fully Qualified Domain Name
   (FQDN) lookup for H should resolve to the correct NID and L32/L64
   records.  If there are many hosts like H that need to keep DNS
   records (for any reason, including to allow incoming ILNP session
   requests), then, potentially, there are many such DNS resource
   records.

   As an optimisation, the network as a whole may be configured with one
   or more L32 and L64 records (to store the value L_1 from our example)
   that are resolved from an FQDN.  At the same time, individual hosts
   now have an FQDN that returns one or more LP record entries [<a href="./rfc6742" title="&quot;DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)&quot;">RFC6742</a>]
   as well as NID records.  The LP record points to the L32 or L64
   records for the site.  A multihomed site normally will have at least
   one L32 or L64 record for each distinct uplink (i.e., link from a
   Site Border Router towards the global Internet), because ILNP uses
   provider-aggregatable addressing.

   More than one L32 or L64 will be required if multiple Locator values
   are in use.  For example, if an ILNPv6 site has multiple links for
   multihoming, it will use one L64 record for each Locator value it is
   using on each link.



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h3"><a class="selflink" id="section-2.7" href="#section-2.7">2.7</a>.  Site Interior Topology Obfuscation</span>

   In some situations, it can be desirable to obfuscate the details of
   the interior topology of an end site.  Alternately, in some
   situations, local site policy requires that local-scope routing
   prefixes be used within the local site.  ILNP can provide these
   capabilities through the ILNP local addressing capability described
   here, under the control of the SBR.

   As described in <a href="#section-2.3">Section 2.3</a> above, locator rewriting can be used to
   hide the internal structure of the network with respect to the
   subnetting arrangement of the site network.  Specifically, the
   procedure described in <a href="#section-2.3">Section 2.3</a> would be followed, with the
   following additional modification of the use of Locator values:

   (1) Only the aggregated Locator value, i.e., L_pp, is advertised
       outside the site (e.g., in an L32 or L64 record), and L_ss is
       zeroed in that advertisement.

   (2) The SBR needs to maintain a mapping table to restore the interior
       topology information for received packets, for example, by using
       a mapping table from I values to either L_ss values or internal
       Locator values.

   (3) The SBR needs to zero the L_ss values for all Source Locators of
       egress packets, as well as perform a Locator rewriting that
       affects the L_pp bits of the Locator value.

   Of course, this only obscures the interior topology of the site, not
   the exterior connectivity of the site.  In order for the site to be
   reachable from the global Internet, the site's DNS entries need to
   advertise Locator values for the site to the global Internet (e.g.,
   in L32, L64 records).

<span class="h3"><a class="selflink" id="section-2.8" href="#section-2.8">2.8</a>.  Other SBR Considerations</span>

   For backwards compatibility, for ILNP, the ICMP checksum is always
   calculated identically as for IPv6 or IPv4.  For ILNPv6, this means
   that the SBR need not be aware if ILNPv6 is operating as described in
   [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>] and [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].  For ILNPv4, again, the SBR need not be
   aware of the operation if ILNPv4 is operating as it will not need to
   inspect the extension header carrying the I value.

   In order to support communication between two internal nodes that
   happen to be using global-scope addresses (for whatever reason), the
   SBR MUST support the "hair pinning" behaviour commonly used in
   existing NAT/NAPT devices.  (This behaviour is described in <a href="./rfc4787#section-6">Section&nbsp;6
   of RFC 4787</a> [<a href="./rfc4787" title="&quot;Network Address Translation (NAT) Behavioral Requirements for Unicast UDP&quot;">RFC4787</a>].)



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   In the near-term, a more common deployment scenario will be to deploy
   ILNP incrementally, with some ordinary classic IP traffic still
   existing.  In this case, the SBR should maintain flow state that
   contains a flag for each flow indicating whether or not that flow is
   using ILNP.  If that flag indicated ILNP were enabled for a given
   flow, and ILNP local numbering were also enabled, then the SBR would
   know that it should perform the simpler ILNP Locator rewriting
   mapping.  If that flag indicated ILNP were not enabled for a given
   flow and IP NAT or IP NAPT were also enabled, then the SBR would know
   that it should perform the more complex NAT/NAPT translation (e.g.,
   including TCP or UDP checksum recalculation).

      NOTE: Existing commercial security-aware routers (e.g., Juniper
      SRX routers) already can maintain flow state for millions of
      concurrent IP flows.  This feature would add one flag to each
      flow's state, so this approach is believed scalable today using
      existing commercial technology.

   Those applications that do not use IP Address values in application
   state or configuration data are considered to be "well behaved".  For
   well-behaved applications, no further enhancements are required.
   Where application-layer protocols are not well behaved, for example,
   the File Transfer Protocol (FTP), then the SBR might need to perform
   additional stateful processing -- just as NAT and NAPT equipment
   needs to do today for FTP.  See the description in <a href="./rfc6741#section-7.6">Section&nbsp;7.6 of
   [RFC6741]</a>.

   When the SBR rewrites a Locator in an ILNP packet, that obscures
   information about how well a particular path is working between the
   sender and the receiver of that ILNP packet.  So, the SBR that
   rewrites Locator values needs to include mechanisms to ensure that
   any packet with a new Destination Locator will travel along a valid
   path to the intended destination node.  For ILNPv4, the path liveness
   will be no worse than IPv4, and mechanisms already in use for IPv4
   can be reused.  For ILNPv6, the path liveness will be no worse than
   for IPv6, and mechanisms already in use for IPv6 can be reused.

   In the future, the Border Router Discovery Protocol (BRDP) also might
   be used in some deployments to indicate which routing prefixes are
   currently valid and which site border routers currently have a
   working uplink [<a href="#ref-BRDP11" title="&quot;BRDP Framework&quot;">BRDP11</a>].










<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  An Alternative for Site Multihoming</span>

   The ILNP Architectural Description [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>] describes the basic
   approach to enabling Site Multihoming (S-MH) with ILNP.  However, as
   an option, it is possible to leave the control of S-MH to an ILNP-
   enabled SBR.  This alternative is based on the use of the Localised
   Numbering function described in <a href="#section-2">Section 2</a> of this document.

<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Site Multihoming (S-MH) Connectivity Using an SBR</span>

   The approach to Site Multihoming (S-MH) using an SBR is best
   illustrated through an example, as shown in Figure 3.1.

          site                         . . . .      +----+
         network         SBR          .       .-----+ CN |
         . . . .      +------+ L_1   .         .    +----+
        .       .     |  sbr1+------.           .
       .         .L_L |      |      .           .
       .         .----+      |      . Internet  .
       .  H      .    |      |      .           .
        .       .     |  sbr2+------.           .
         . . . .      +------+ L_2   .         .
                                     .       .
                                      . . . .

             CN = Correspondent Node
              H = Host
            L_1 = global Locator value 1
            L_2 = global Locator value 2
            L_L = local Locator value
            SBR = Site Border Router
           sbrN = interface N on SBR

    Figure 3.1: Alternative Site Multihoming Example with an SBR

   The situation here is similar to the localised numbering example,
   except that the SBR now has two external links, with using Locator
   value L_1 and another using Locator value L_2.  These could, e.g.,
   for ILNPv6, be separate, Provider Aggregated (PA) IPv6 prefixes from
   two different ISPs.  H has IL-V [I_H, L_L], and will forward a packet
   to CN as given in expression (1a).  However, when the packet reaches
   the SBR, local policy will decide whether the packet is forwarded on
   the link sbr1 using L_1 or on sbr2 using L_2.  Of course, the correct
   Locator value will be rewritten into the egress packet in place of
   L_L.






<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   If only local numbering is being used, then the SBR need never
   advertise any global Locator values.  However, it could do, as
   described in <a href="#section-2.2">Section 2.2</a>.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Dealing with Link/Connectivity Changes</span>

   One of the key uses for multihoming is providing resilience to link
   failure.  If either link breaks, then the SBR can manage the change
   in connectivity locally.  For example, assume SBR has been configured
   to use sbr1 for all traffic, and sbr2 only as backup link.  So, SBR
   directs packets from H to communicate with CN using sbr1, and CN will
   receive packets as in expression (1b) and respond with packets as in
   expression (2a).

   However, if sbr1 goes down then SBR will move the communication to
   interface sbr2.  As H is not aware of the actions of the SBR, the SBR
   must maintain some state about IL-V "pairs" in order to hand off the
   connectivity from sbr1 to sbr2.  So, when moving the communication to
   sbr2, the SBR would firstly send a Locator Update (LU) message
   [<a href="./rfc6745" title="&quot;ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)&quot;">RFC6745</a>] [<a href="./rfc6743" title="&quot;ICMPv6 Locator Update Message&quot;">RFC6743</a>], to CN informing it that L_2 is now the valid
   Locator for the communication.  This operation would not be visible
   to H, although there might be some disruption to transmission, e.g.,
   packets being sent from CN to H that are in flight when sbr1 goes
   down may be lost.  The SBR might also need to update DNS entries (see
   <a href="#section-3.3">Section 3.3</a>).  Since ILNP requires that all Locator Update messages
   be authenticated by the ILNP Nonce, the SBR will need to include the
   appropriate Nonce values as part of its cache of information about
   ILNP sessions traversing the SBR.  (NOTE: Since commercial security
   gateways available as of this writing reportedly can handle full
   stateful packet inspection for millions of flows at multi-gigabit
   speeds, it should be practical for such devices to cache the ILNP
   flow information, including Nonce values.)

   This approach has some efficiency gains over the approach for
   multihoming described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], where each hosts manages its own
   connectivity.

   If sbr1 was to be reinstated, now with Locator value L_3, then local
   policy would determine if the communication should be moved back to
   sbr1, with appropriate additional actions, such as transmission of LU
   messages with the new Locator values and also the updates to DNS.

   Note that in such movement of an ILNP session across interfaces at
   the SBR, only Locator values in ILNP packets are changed.  As already
   noted in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], end-to-end transport-layer session state
   invariance is maintained.





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  SBR Updates to DNS</span>

   When the SBR manages connectivity as described above, the internal
   hosts, such as H, are not necessarily aware of any connectivity
   changes.  Indeed, there is certainly no requirement for them to be
   aware.  So, if H was a server expecting incoming connections, the SBR
   must update the relevant DNS entries when the site connectivity
   changes.

   There are two possibilities: each host could have its own L32 or L64
   records; or the site might use a combination of LP and L32/L64
   records (see <a href="#section-2.4">Section 2.4</a>).  Either way, the SBR would need to update
   the relevant DNS entries.  For our example, with ILNPv6 and LP
   records in use, the SBR would need to manage two L64 records (one for
   each uplink) that would resolve from a FQDN, for example,
   site.example.com.  Meanwhile, individual hosts, such as H, have an
   FQDN that resolves to an NID value and an LP record that would
   contain the value site.example.com, which then would be used to look
   up the two L64 records.

   If the SBR is multihomed, as in Figure 3.1, then it will have (at
   least) two Locator values, one for each link, and local policy will
   need to be used to determine how preference values are applied in the
   relevant L32 and L64 records.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  DNS TTL Values for L32 and L64 Records</span>

   Imagine that in the scenario described above, there was a link
   failure that resulted in sbr1 going down and sbr2 was used.  Existing
   ILNP sessions in progress would move to sbr2 as described above.
   However, new incoming ILNP sessions to the site would need to know to
   use L_2 and not L_1.  L_1 and L_2 would be stored in DNS records
   (e.g., L32 for ILNPv4 or L64 for ILNPv6).  If a remote host has
   already resolved from DNS that L_1 is the correct Locator for sending
   packets to the site, then that host might be holding stale
   information.

   DNS allows values returned to be aged using Time-To-Live (TTL), which
   is specified in the time unit of seconds.  So that remote nodes do
   not hold on to stale values from DNS, the L64 records for our site
   should have low TTL values.  An appropriate value must be considered
   carefully.  For example, let us assume that the site administrator
   knows that when sbr1 fails, it takes 20 seconds to failover to sbr2.
   Then, 20 s would seem to be an appropriate time to use for the TTL
   value of an L64 for the site: if a remote node had just resolved the
   value L_1 for the site, and the link to sbr1 went down, that remote
   node would not hold the stale value of L_1 for any longer than it
   takes the site to failover to sbr2 and use L_2.



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Our studies for a university school site network show that low TTL
   values, as low as zero, are feasible for operational use [<a href="#ref-BA11" title="&quot;Reducing DNS Caching&quot;">BA11</a>].

   NOTE: From 01 November 2010, the site network of the School of
         Computer Science, University of St Andrews, UK, has been
         running operational DNS with DNS A records that have TTL of
         zero.  At the time of writing of this document (November 2012),
         a zero DNS TTL was still in use at the school.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Multiple SBRs</span>

   For site multihoming, with multiple SBRs, a situation may be as
   follows (see also <a href="./rfc6740#section-5.3.1">Section&nbsp;5.3.1 in [RFC6740]</a>).

         site                          . . . .
        network                       .       .
        . . . .      +-------+ L_1   .         .
       .       .     |       +------.           .
      .         .    |       |      .           .
     .           .---+ SBR_A |      .           .
     .           .   |       |      .           .
     .           .   |       |      .           .
     .           .   +-------+      .           .
     .           .       ^          .           .
     .           .       | CP       . Internet  .
     .           .       v          .           .
     .           .   +-------+ L_2  .           .
     .           .   |       +------.           .
     .           .   |       |      .           .
     .           .---+ SBR_B |      .           .
      .         .    |       |      .           .
       .       .     |       |      .           .
        . . . .      +-------+       .         .
                                      .       .
                                       . . . .

         CP     = coordination protocol
         L_1    = global Locator value 1
         L_2    = global Locator value 2
         SBR_A  = Site Border Router A
         SBR_B  = Site Border Router P

   Figure 3.2: A Dual-Router Multihoming Scenario for ILNP

   The use of two physical routers provides an extra level of resilience
   compared to the scenario of Figure 3.1.  The coordination protocol
   (CP) between the two routers keeps their actions in synchronisation
   according to whatever management policy is in place for the site



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   network.  Such functions are available today in some commercial
   network security products.  Note that, logically, there is little
   difference between Figures 5.1 and 3.2, but with two distinct routers
   in Figure 3.2, the interaction using CP is required.  Of course, it
   is also possible to have multiple interfaces in each router and more
   than two routers.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  An Alternative for Site (Network) Mobility</span>

   The ILNP Architectural Description [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>] describes the basic
   approach to enabling site (network) mobility with ILNP.  However, as
   an option, it is possible to leave the control of site mobility to an
   ILNP-enabled SBR by exploiting the alternative site multihoming
   feature described in <a href="#section-3">Section 3</a> of this document.

   Again, as described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], we exploit the duality between
   mobility and multihoming for ILNP.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Site (Network) Mobility</span>

   Let us consider the mobile network in Figure 4.2, which is taken from
   [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>].

          site                        ISP_1
         network        SBR           . . .
         . . . .      +------+ L_1   .     .
        .       . L_L |   ra1+------.       .
       .         .----+      |      .       .
        .  H    .     |   ra2+--    .       .
         . . . .      +------+       .     .
                                      . . .

       Figure 4.1a: ILNP Mobile Network before Handover

          site                        ISP_1
         network        SBR           . . .
         . . . .      +------+ L_1   .     .
        .       . L_L |   ra1+------. . . . .
       .         .----+      |      .       .
        .  H    .     |   ra2+------.       .
         . . . .      +------+ L_2  . . . . .
                                     .     .
                                      . . .
                                      ISP_2

       Figure 4.1b: ILNP Mobile Network during Handover





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


          site                        ISP_2
         network        SBR           . . .
         . . . .      +------+       .     .
        .       . L_L |   ra1+--    .       .
       .         .----+      |      .       .
        .  H    .     |   ra2+------.       .
         . . . .      +------+ L_2   .     .
                                      . . .

       Figure 4.1c: ILNP Mobile Network after Handover

            H = host
          L_1 = global Locator value 1
          L_2 = global Locator value 2
          L_L = local Locator value
          raN = radio interface N
          SBR = Site Border Router

     Figure 4.1: An Alternative Mobile Network Scenario with an SBR

   We assume that the site (network) is mobile, and the SBR has two
   radio interfaces, ra1 and ra2.  In the figure, ISP_1 and ISP_2 are
   separate, radio-based service providers, accessible via interfaces
   ra1 and ra2.

   While the SBR makes the transition from using a single link (Figure
   4.1a) to the handover overlap on both links (Figure 4.1b), to only
   using a single link again (Figure 4.1c), the host H continues to use
   only Locator value L_L, as already described for Site Multihoming
   (S-MH).  During this time the actions taken by the SBR are the same
   as already described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>], except that the SBR:

   a) also performs that ILNP localised numbering function described in
      <a href="#section-2">Section 2</a>.

   b) does not need to advertise L_1 and L_2 internally if only local
      numbering is being used.

   As for the case of S-MH above, H need not be aware of the change in
   connectivity for the SBR if it is only using local numbering, and the
   SBR would send LU messages for H (for any correspondent nodes, not
   shown in Figure 4.1), and would update DNS entries as required.

   The difference to the S-MH scenario described earlier in this
   document is that in the situation of Figure 4.1b, the SBR can opt to
   use soft handover has previously described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>].





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Again, there is an efficiency gain compared to the situation
   described in [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>]: the SBR provides a convenient point at which
   to centrally manage the movement of the site as a whole.  Note that
   in Figure 4.1b, the site is multihomed.

   As for S-MH, L_1 and L_2 could be advertised internally, as a local
   policy decision, for those hosts that require direct control of their
   connectivity.

   Note that for handover, immediate handover will have a similar
   behaviour to a link outage as described for S-MH.  However, as ILNP
   allows soft-handover, during the handover period, this should help to
   reduce (perhaps even remove) packet loss.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  SBR Updates to DNS</span>

   As for S-MH, a similar discussion to <a href="#section-3.3">Section 3.3</a> applies for mobile
   networks with respect to the updates to DNS.  As a mobile network is
   likely to have more frequent changes to its connectivity than a
   multihomed network would due to connectivity changes, the use of LP
   DNS records is likely to be particularly advantageous here.

<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  DNS TTL Values for L32 and L64 Records</span>

   As for S-MH, a similar discussion to <a href="#section-3.4">Section 3.4</a> applies for mobile
   networks with respect to the TTL of L32 and/or L64 records that are
   used for the name of the mobile network.  In the case of the mobile
   network, it makes sense for the TTL to be aligned to the time for
   handover.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Traffic Engineering Options</span>

   The use of Locator rewriting provides some simple yet useful options
   for traffic engineering (TE) controlled from the edge-site via the
   SBR, requiring no cooperation from the service provider other than
   the provision of basic connectivity services, e.g., physical
   connectivity, allocation of IP Address prefixes and packet
   forwarding.  This does not preclude other TE options that are already
   in use, such as use of MPLS, but we choose to highlight here the
   specific options available and controllable solely through the use of
   ILNP.

   When a site network is multihomed, we have seen that the use of the
   Locator rewriting function permits the SBR to have packet-by-packet
   control when forwarding on external links.  Various configuration and
   policies could be applied at the SBR in order to control the egress
   and ingress traffic to the site network.




<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Load Balancing</span>

   Let us consider Figure 5.1, and assume ILNP local numbering is in
   use; that H1, H2, and H3 use, respectively, Identifier values, I_1,
   I_2 and I_3; and all of them use Locator value L_L.

           site                         . . . .
          network         SBR          .       .
          . . . .      +------+ L_1   .         .
         .       .     |  sbr1+------.           .
        .     H2  .L_L |      |      .           .
        . H3      .----+      |      . Internet  .
        .         .    |      |      .           .
         .  H1   .     |  sbr2+------.           .
          . . . .      +------+ L_2   .         .
                                       .       .
                                        . . . .

            HN = host N
           L_1 = global Locator value 1
           L_2 = global Locator value 2
           L_L = local Locator value
           SBR = Site Border Router
          sbrN = interface N on sbr

      Figure 5.1: A Site Multihoming Scenario for Traffic Control

   The SBR could be configured, subject to local policy, to try to
   control load across the external links.  For example, it could be
   configured initially with the following mappings:

     srcI=I_1, sbr1                                        --- (3a)
     srcI=I_2, sbr2                                        --- (3b)
     srcI=I_3, sbr1                                        --- (3c)

   These mappings direct packets matching course Identifier values to
   particular outgoing interfaces.  As load changes, these mappings
   could be changed.  For example, expression (3c) could be changed to:

     srcI=I_3, sbr2                                        --- (4)

   and the SBR would need to send LU message to the correspondents of H3
   (sbr to uses L_2 while sbr1 uses L_1).  The egress connectivity is
   totally within control of the SBR under administrative policy, as
   already seen in the descriptions of multihoming and mobility in this
   document.





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Of course, more complex policies are possible, based on:

    - whether ILNP sessions are incoming or outgoing
    - time of day
    - internal subnets

   and any number of criteria already in use for control of traffic.

   In expressions (3a,b,c) above, source I values are used.  However:

    - destination I values could be used
    - source or destination L values could be used
    - mappings could be to L values, not to specific interfaces

   and, again, any number of criteria could be used to manipulate the
   packet path, based on filtering of values in header fields and local
   policy.

   With ILNP, hosts do not need to be aware of the operation of the SBR
   in this manner.

   Note, again, that in this scenario, there is nothing to prevent SBR
   from also advertising L_1 and L_2 into the site network.  If
   required, administrative controls could be used to enable selective
   hosts in the site network to use L_1 and L_2 directly as described in
   [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>].

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Control of Egress Traffic Paths</span>

   Extending the scenario for load-balancing described above, it is also
   be possible for the ILNP-capable SBR to direct traffic along specific
   network paths based on the use of different L values, i.e., by using
   multiple prefixes assigned from upstream providers.

   Of course, as previously discussed, these prefixes can be Provider
   Aggregated (PA) and need not be Provider Independent (PI).

   Let us consider Figure 5.2 and assume ILNP local numbering is in use;
   that H1, H2 and H3 use, respectively, Identifier values, I_1, I_2,
   and I_3; and all of them use Locator value L_L.  Let us also assume
   that the node CN uses IL-V [I_CN, L_CN].










<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


           site                           . . . .      +----+
          network         SBR            .       .-----+ CN |
          . . . .      +------+ L1,L2   .         .    +----+
         .       .     |  sbr1+--------.           .
        .     H2  .L_L |      |        .           .
        . H3      .----+  sbr2+--------. Internet  .
        .         .    |      | L3,L4  .           .
        .         .    |      |        .           .
         .  H1   .     |  sbr3+--------.           .
          . . . .      +------+ L5,L6   .         .
                                         .       .
                                          . . . .

            CN = correspondent node
            HN = host N
            LN = global Locator value N
           L_L = local Locator value
           SBR = Site Border Router
          sbrN = interface N on sbr

      Figure 5.2: A Site Multihoming Scenario for Traffic Control

   Here, many configurations are possible.  For example, for egress
   traffic:

     srcI=I_2, L2                                          --- (5a)
     srcI=I_3, L3                                          --- (5b)
     dstI=I_CN, L6                                         --- (5c)
     srcI=I_1 dstI=I_CN, L1                                --- (5d)

   Expression (5a) maps all egress packets from H2 to have their source
   Locator value rewritten to L2 (and implicitly to use interface sbr1).
   Expression (5b) maps all egress packets from H3 to have their source
   Locator value rewritten to L3 (and implicitly to use interface sbr2).
   Expression (5c) directs any traffic to CN to use Locator value L6 as
   the source Locator (and implicitly to use interface sbr3), and may
   override (5a) and (5b), subject to local policy, when packets to CN
   are from H2 or H3.

   Meanwhile, in expression (5d), we see a further, more specific rule,
   in that packets from H1 destined to CN should use Locator value L1
   (and implicitly to use interface sbr1).

   Note the implicit bindings to interfaces in expressions (5a,b,c,d),
   compared to the explicit bindings in expressions (3a,b,c).  ILNP only
   requires that the Locator values are correctly rewritten and packets
   forwarded in conformance with the routing already configured for the
   Locator values.



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Of course, these rules can be changed dynamically at the SBR, and the
   SBR will migrate ILNP sessions across Locator values, as already
   described above for mobility.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  ILNP in Datacentres</span>

   As ILNP has first class support for mobility and multihoming, and
   supports flexible options for localised addressing, there is great
   potential for it to be used in datacentre scenarios.  Further details
   of possibilities are in [<a href="#ref-BA12" title="&quot;Secure &amp; Agile Wide-area Virtual Machine Mobility&quot;">BA12</a>], with a summary presented here.

   There are several scenarios that could be beneficial to datacentres,
   in order to provide functions such as load balancing, resilience and
   fault tolerance, and resource management:

   - Same datacentre, internal Virtual Machine (VM) mobility: This could
     be beneficial in load balancing, dynamically, where load changes
     are taking place.  The remote user does not see the VM has moved.

   - Different datacentres, transparent mobility: This is where the
     datacentre resources may be geographically distributed, but the
     geographical movement is transparent to the remote user.

   - Different datacentres, mobility is visible: This is where the
     datacentre resources may be geographically distributed, but the
     geographical movement is visible to the remote user.

   These are three situations that may be supported by ILNP, but they
   are not the only ones: we provide these here as examples, and they
   are not intended to be prescriptive.  The intention is only to show
   the flexibility that is possible through the use of ILNP.

   This section describes some Virtual Machine (VM) mobility
   capabilities that are possible with ILNP.  Depending on the internal
   details and virtualisation model provided by a VM platform, it might
   be sufficient for the guest operating system to support ILNP.  In
   some cases, again depending on the internal details and
   virtualisation model provided by a VM platform, the VM platform
   itself also might need to include support for ILNP.

   Details of how a particular VM platform works, and which
   virtualisation model(s) a VM platform supports, are beyond the scope
   of this document.  Internal implementation details of VM platform
   support for ILNP are also beyond the scope of this document, just as
   internal implementation details for any other networked system
   supporting ILNP are beyond the scope of this document.





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Virtual Image Mobility within a Single Datacentre</span>

   Let us consider first the scenario of Figure 6.1, noting its
   similarity to Figure 2.1 for use of localised numbering.

          site                         . . . .      +----+
         network        SBR           .       .-----+ CN |
         . . . .      +------+ L_1   .         .    +----+
        .       .     |      +------.           .
       .    H2   .L_L |      |      .           .
       .         .----+      |      . Internet  .
       .  V*H1   .    |      |      .           .
        .       .     |      |      .           .
         . . . .      +------+       .         .
                                      .       .
                                       . . . .

            CN = Correspondent Node
             V = Virtual machine image
            Hx = Host x
           L_1 = global Locator value
           L_L = local Locator value
          SBR = Site Border Router

     Figure 6.1: A Simple Virtual Image Mobility Example for ILNP

   L_L is a Locator value used for the ILNP hosts H1 and H2.  Here, the
   "V*H1" signifies that the virtual machine image V is currently
   resident on H1.  Let us assume that V has Identifier I_V.  Note that
   as H1 and H2 have the same Locator value (L_1), as far as CN is
   concerned, it does not matter if V is resident on H1 or H2, all
   transport packets between V and CN will have the same signature as
   far as CN is concerned, e.g., for a UDP flow (in analogy to (1a)):

     &lt;UDP: I_V, I_CN, P_V, P_CN&gt;&lt;ILNP: L_1, L_CN&gt;           --- (6a)

   Now, if V was to migrate to H2, the migration would be an issue
   purely local to the site network, and the end-to-end integrity of the
   transport flow would be maintained.

   Of course, there are practical operating systems issues in enabling
   such a migration locally, but products exist today that could be
   modified and made ILNP-aware in order to enable such VM image
   mobility.

   Note that for convenience, above, we have used localised numbering
   for ILNP, but if local Locator values were not used and the whole
   site simply used L_1, the principle would be the same.



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Virtual Image Mobility between Datacentres - Invisible</span>

   Let us now consider an extended version of the scenario above in Fig.
   6.2, where we see that there is a second site network, which is
   geographically distant to the first site network, and the two site
   networks are interconnected via their respective SBRs.

          site                         . . . .      +----+
         network 1      SBR1          .       .-----+ CN |
         . . . .      +------+ L_1   .         .    +----+
        .       .     |      +------.           .
       .         .L_L1|      |      .           .
       .         .----+      |      . Internet  .
       .  V*H1   .    |      |      .           .
        .       .     |      |      .           .
         . . . .      +---+--+      .           .
                          :         .           .
                          :         .           .
         . . . .      +---+--+ L_2  .           .
        .       .     |      +------.           .
       .    H2   .L_L2|      |      .           .
       .         .----+      |      .           .
       .         .    |      |      .           .
        .       .     |      |      .           .
         . . . .      +------+       .         .
          site          SBR2          .       .
         network 2                     . . . .

             : = logical inter-router link and coordination
            CN = Correspondent Node
             V = Virtual machine image
            Hx = Host x
           L_y = global Locator value y
          L_Lz = local Locator value z
          SBR = Site Border Router

     Figure 6.2: A Simple Localised Numbering Example for ILNP

   Note that the logical inter-router link between SBR1 and SBR2 could
   be realised physically in many different ways that are available
   today and are not ILNP-specific, e.g., leased line, secure IP-layer
   or Layer 2 tunnel, etc.  We assume that this link also allows
   coordination between the two SBRs.  For now, we ignore external link
   L_2 on SBR2, and assume that the remote node, CN, is in communication
   with V through SBR1.






<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   When in initial communication, the packets have the signature is
   given in expression (6a).  When V moves to H2, it now uses Locator
   value L_L2, but all communication between V and CN is still routed
   via SBR1.  So, the remote CN still sees that same packet signature as
   given in expression (6a).  L_L1 and L_L2 are, effectively, two
   internal (private) subnetworks, and are not visible to CN.

   However, SBR2 and SBR1 must coordinate so that any further
   communication to V via SBR1 is routed across the inter-router link.
   Again, there are commercial products today that could be adapted to
   manage such shared state.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Virtual Image Mobility between Datacentres - Visible</span>

   Clearly, in the scenario of the section above, once V has moved to
   site network 2, it may be beneficial, for a number of reasons, for
   communication to V to be routed via SBR2 rather than SBR1.

   When V moves from site network 1 to site network 2, this visibility
   of mobility could be by V sending ILNP Locator Update messages to the
   CN during the mobility process.  Also, V would update any relevant
   ILNP DNS records, such as L64 records, for new ILNP session requests
   to be routed via SBR2.

   Indeed, let us now consider again Figure 6.2, and assume now that
   Local locators L_L1 and L_L2 are not in use on either site network,
   and each site networks uses its own global Locator value, L_1 and
   L_2, respectively, internally.  In that case, the packet flow
   signature for V when it is in site network 1 as viewed from CN is,
   again as given in expression (6a).  However, when V moves to site
   network 2, it would simply use L_2 as its new Locator, send Locator
   Update messages to CN as would a normal mobile node for ILNP, and
   complete its migration to H2.  Then, CN would see the packet
   signatures as in expression (6b).

     &lt;UDP: I_V, I_CN, P_V, P_CN&gt;&lt;ILNP: L_2, L_CN&gt;           --- (6b)

   In this case, no "special" inter-router link is required for mobility
   -- the normal Internet connectivity between SBR1 and SBR2 would
   suffice.  However, it is quite likely that some sort of tunnelled
   link would still be desirable to offer protection of the VM image as
   it migrates.

<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>.  ILNP Capability in the Remote Host for VM Image Mobility</span>

   For the remote host -- the CN -- the availability of ILNP would be
   beneficial.  However, for the first two scenarios listed above, as
   the packet signature of the transport flows remains fixed from the



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   viewpoint of the CN, it seems possible that the benefits of ILNP VM
   mobility could be used for datacentres even while CNs remain as
   normal IP hosts.  Of course, a major caveat here is that the
   application level protocols should be "well behaved": that is, the
   application protocol or configuration should not rely on the use of
   IP Addresses.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Location Privacy</span>

   Extending the Locator rewriting paradigm, it is possible to also
   enable Location privacy for ILNP by a modified version of the "onion
   routing" paradigm that is used for Tor [<a href="#ref-DMS04" title="&quot;Tor: the second-generation onion router&quot;">DMS04</a>] [<a href="#ref-RSG98" title="&quot;Anonymous Connections and Onion Routing&quot;">RSG98</a>].

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Locator Rewriting Relay (LRR)</span>

   To enable this function, we use a middlebox that we call the Locator
   Rewriting Relay.  The function of this unit is described by the use
   of Figure 7.1.

      &lt;UDP: I_H, I_CN, P_H, P_CN&gt;&lt;ILNP: L_1, L_CN&gt;         --- (7a)

              v
              |
           +--+--+
           |     |   src=[I_H, L_1], L_X                   --- (7b)
           | LRR |   dst=[I_H, L_X], L_1                   --- (7c)
           |     |
           +--+--+
              |
              v
      &lt;UDP: I_H, I_CN, P_H, P_CN&gt;&lt;ILNP: L_X, L_CN&gt;         --- (7d)

        LRR = Locator Rewriting Relay

     Figure 7.1: Locator Rewriting Relay (LRR) Example

   The operation of the LRR is conceptually very simple.  We assume that
   the LRR first has mappings as given in expressions (7b) and (7c) (see
   next subsection).  Expression (7b) says that for packets with src
   IL-V [I_H, L_1], the packet's source Locator value should be
   rewritten to value L_X and then forwarded.  Expression (7c) has the
   complimentary mapping for packets with destination IL-V [I_H, L_1]
   (for the reverse direction).

   Expression (6a) is a UDP/ILNP packet as might be sent in Figure 2.1
   from H to CN.  However, instead of going directly to L_CN, the packet
   with destination Locator L_1 goes to a LRR.  Expression (7d) is the
   result of the mapping of packet (7a) using expression (7b).



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   Note that it is entirely possible that the packet of expression (7d)
   then is processed by another LRR for source Locator value L_X.
   Effectively, this creates and LRR path for the packet, as an overlay
   path on top of the normal IP routing.

   In this way, there is a level of protection, without the need for
   cryptographic techniques, for the (topological) Location of the
   packet.  Of course, an extremely well-resourced adversary could,
   potentially, backtrack the LRR path, but, depending on the LRR
   overlay path that is created, could be very difficult to trace in
   reality.  For example, the mechanism will protect against off-path
   attacks, but where the threat regime includes the potential for on-
   path attacks, cryptographically protected tunnels between H and LRR
   might be required.

   Again, as the Locator value is not part of the end-to-end state, this
   mechanism is very general and has a low overhead.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Options for Installing LRR Packet Forwarding State</span>

   There are many options for managing the "network" of LRRs that could
   be in place if such a system was used on a large scale, including the
   setting up and removal of LRR state for packet relaying, as for
   expressions (7b) and (7c).  We consider this function to be outside
   the scope of these ILNP specifications, but note that there are many
   existing mechanisms that could modified for use, and also many
   possibilities for new mechanisms that would be specific to the use of
   ILNP LRRs.

   (Note also that the control/management communication with the LRR
   does not need to use ILNP: IPv4 or IPv6 could be used.)

   The host, H, by itself could install the required state, assuming it
   was aware of suitable information to contact the LRR.  The first
   packet in an ILNP session might contain a header option called a
   Locator Redirection Option (LRO).  The LRO would contain the Locator
   value that should be rewritten into the source Locator of the packet.
   When a LRR receives such a packet, it would install the required
   state.  Such a mechanism could be soft-state, requiring periodic use
   of the LRO in order to maintain the state in the LRR.  The LRO could
   also be delivered using an ICMP ECHO packet sent from H to the LRR,
   periodically, again to maintain a soft-state update.

   It would, of course, be prudent to protect the LRR state control
   packets with some sort of authentication token, to prevent an
   adversary from easily installing false LRR state and causing packets





<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   from H or its correspondent to be subject to man-in-the-middle
   attacks, or black-holing.  Again, such attacks are not specific to
   ILNP or new to ILNP.

   It would also be possible to use proprietary application level
   protocols, with strong authentication for the control of the LRR
   state.  For example, an application level protocol based on XMPP
   (<a href="http://xmpp.org/">http://xmpp.org/</a>) operating over SSL.

   Above, we have offered very brief and incomplete descriptions of some
   possibilities, and we do not necessarily mandate any one of them:
   they serve only as examples.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Identity Privacy</span>

   For the sake of completeness, and in complement to <a href="#section-6">Section 6</a>, it
   should be noted that ILNP can use either cryptographically verifiable
   Identifier values, or use Identifier values that provide a level of
   anonymity to protect a user's privacy.  More details are given in
   Sections <a href="#section-2">2</a> and <a href="#section-11">11</a> of [<a href="./rfc6741" title="&quot;Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations&quot;">RFC6741</a>].

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Security Considerations</span>

   The relevant security considerations to this document are the same as
   for the main ILNP Architectural Description [<a href="./rfc6740" title="&quot;Identifier-Locator Network Protocol (ILNP) Architectural Description&quot;">RFC6740</a>].  The one
   additional point to note is that this document describes ILNP
   capability in the SBR and so those adversaries wishing to subvert the
   operation of ILNP specifically, have a target that would,
   potentially, disable an entire site.  However, this is not an attack
   vector that is specific to ILNP: today, disruption of an IPv4 or IPv6
   SBR would have the same impact.

   The security considerations for <a href="#section-7">Section 7</a> (Location Privacy) are
   already documented in [<a href="#ref-DMS04" title="&quot;Tor: the second-generation onion router&quot;">DMS04</a>] and [<a href="#ref-RSG98" title="&quot;Anonymous Connections and Onion Routing&quot;">RSG98</a>].  One possibility is that
   the LRR mechanism itself could be used by an adversary to launch an
   attack and hide his own (topological) Location, for example.  This is
   already possible for IPv4 and IPv4 with a Tor-like system today, so
   is not new to ILNP.













<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  References</span>

<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>.  Normative References</span>

   [<a id="ref-RFC1918">RFC1918</a>]     Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
                 G., and E. Lear, "Address Allocation for Private
                 Internets", <a href="https://www.rfc-editor.org/bcp/bcp5">BCP 5</a>, <a href="./rfc1918">RFC 1918</a>, February 1996.

   [<a id="ref-RFC2119">RFC2119</a>]     Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC3022">RFC3022</a>]     Srisuresh, P. and K. Egevang, "Traditional IP Network
                 Address Translator (Traditional NAT)", <a href="./rfc3022">RFC 3022</a>,
                 January 2001.

   [<a id="ref-RFC3484">RFC3484</a>]     Draves, R., "Default Address Selection for Internet
                 Protocol version 6 (IPv6)", <a href="./rfc3484">RFC 3484</a>, February 2003.

   [<a id="ref-RFC4193">RFC4193</a>]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                 Addresses", <a href="./rfc4193">RFC 4193</a>, October 2005.

   [<a id="ref-RFC4632">RFC4632</a>]     Fuller, V. and T. Li, "Classless Inter-domain Routing
                 (CIDR): The Internet Address Assignment and Aggregation
                 Plan", <a href="https://www.rfc-editor.org/bcp/bcp122">BCP 122</a>, <a href="./rfc4632">RFC 4632</a>, August 2006.

   [<a id="ref-RFC4787">RFC4787</a>]     Audet, F., Ed., and C. Jennings, "Network Address
                 Translation (NAT) Behavioral Requirements for Unicast
                 UDP", <a href="https://www.rfc-editor.org/bcp/bcp127">BCP 127</a>, <a href="./rfc4787">RFC 4787</a>, January 2007.

   [<a id="ref-RFC4864">RFC4864</a>]     Van de Velde, G., Hain, T., Droms, R., Carpenter, B.,
                 and E. Klein, "Local Network Protection for IPv6", <a href="./rfc4864">RFC</a>
                 <a href="./rfc4864">4864</a>, May 2007.

   [<a id="ref-RFC4924">RFC4924</a>]     Aboba, B., Ed., and E. Davies, "Reflections on Internet
                 Transparency", <a href="./rfc4924">RFC 4924</a>, July 2007.

   [<a id="ref-RFC4984">RFC4984</a>]     Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed.,
                 "Report from the IAB Workshop on Routing and
                 Addressing", <a href="./rfc4984">RFC 4984</a>, September 2007.

   [<a id="ref-RFC5902">RFC5902</a>]     Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts
                 on IPv6 Network Address Translation", <a href="./rfc5902">RFC 5902</a>, July
                 2010.

   [<a id="ref-RFC6177">RFC6177</a>]     Narten, T., Huston, G., and L. Roberts, "IPv6 Address
                 Assignment to End Sites", <a href="https://www.rfc-editor.org/bcp/bcp157">BCP 157</a>, <a href="./rfc6177">RFC 6177</a>, March
                 2011.




<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   [<a id="ref-RFC6740">RFC6740</a>]     Atkinson, R. and S. Bhatti, "Identifier-Locator Network
                 Protocol (ILNP) Architectural Description", <a href="./rfc6740">RFC 6740</a>,
                 November 2012.

   [<a id="ref-RFC6741">RFC6741</a>]     Atkinson, R. and S. Bhatti, "Identifier-Locator Network
                 Protocol (ILNP) Engineering and Implementation
                 Considerations", <a href="./rfc6741">RFC 6741</a>, November 2012.

   [<a id="ref-RFC6742">RFC6742</a>]     Atkinson, R., Bhatti, S. and S. Rose, "DNS Resource
                 Records for the Identifier-Locator Network Protocol
                 (ILNP)", <a href="./rfc6742">RFC 6742</a>, November 2012.

   [<a id="ref-RFC6743">RFC6743</a>]     Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update
                 Message", <a href="./rfc6743">RFC 6743</a>, November 2012.

   [<a id="ref-RFC6744">RFC6744</a>]     Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination
                 Option for the Identifier-Locator Network Protocol for
                 IPv6 (ILNPv6)", <a href="./rfc6744">RFC 6744</a>, November 2012.

   [<a id="ref-RFC6745">RFC6745</a>]     Atkinson, R. and S. Bhatti,  "ICMP Locator Update
                 Message for the Identifier-Locator Network Protocol for
                 IPv4 (ILNPv4)", <a href="./rfc6745">RFC 6745</a>, November 2012.

   [<a id="ref-RFC6746">RFC6746</a>]     Atkinson, R. and S.Bhatti, "IPv4 Options for the
                 Identifier-Locator Network Protocol (ILNP)", <a href="./rfc6746">RFC 6746</a>,
                 November 2012.

   [<a id="ref-RFC6747">RFC6747</a>]     Atkinson, R. and S. Bhatti, "Address Resolution
                 Protocol (ARP) Extension for the Identifier-Locator
                 Network Protocol for IPv4 (ILNPv4)", <a href="./rfc6747">RFC 6747</a>, November
                 2012.

<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>.  Informative References</span>

   [<a id="ref-ABH07a">ABH07a</a>]      Atkinson, R., Bhatti, S., and S. Hailes, "Mobility as
                 an Integrated Service Through the Use of Naming",
                 Proceedings of ACM Workshop on Mobility in the Evolving
                 Internet Architecture (MobiArch), ACM SIGCOMM, Kyoto,
                 Japan. 27 Aug 2007.

   [<a id="ref-ABH07b">ABH07b</a>]      Atkinson, R., Bhatti, S., and S. Hailes, "A Proposal
                 for Unifying Mobility with Multi-Homing, NAT, &amp;
                 Security", Proceedings of 2nd ACM Workshop on Mobility
                 Management and Wireless Access (MobiWAC), ACM, Chania,
                 Crete, Oct 2007.  ISBN: 978-1-59593-809-1






<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   [<a id="ref-ABH08a">ABH08a</a>]      Atkinson, R., Bhatti, S., and S. Hailes, "Mobility
                 Through Naming: Impact on DNS", Proceedings of 3rd ACM
                 Workshop on Mobility in the Evolving Internet
                 Architecture (MobiArch), ACM SIGCOMM, Seattle, WA, USA.
                 Aug 2008.

   [<a id="ref-ABH08b">ABH08b</a>]      Atkinson, R., Bhatti, S., and S. Hailes, "Harmonised
                 Resilience, Security, and Mobility Capability for IP",
                 Proceedings of the IEEE Military Communications
                 Conference (MILCOM), IEEE, San Diego, CA, USA, Nov
                 2008.

   [<a id="ref-ABH09a">ABH09a</a>]      Atkinson, R, Bhatti, S., and S. Hailes, "Site-
                 Controlled Secure Multi-Homing and Traffic Engineering
                 For IP", Proceedings of IEEE Military Communications
                 Conference (MILCOM), IEEE, Boston, MA, USA, Oct 2009.

   [<a id="ref-ABH09b">ABH09b</a>]      Atkinson, R., Bhatti, S., and S. Hailes, "ILNP:
                 Mobility, Multi-Homing, Localised Addressing and
                 Security Through Naming"", Telecommunication Systems",
                 vol. 42, no. 3-4, pp 273-291, Springer-Verlag, Dec
                 2009.

   [<a id="ref-ABH10">ABH10</a>]       Atkinson, R., Bhatti, S., and S. Hailes, "Evolving the
                 Internet Architecture Through Naming", IEEE Journal on
                 Selected Areas in Communication (JSAC), vol. 28, no. 8,
                 pp 1319-1325, IEEE, Oct 2010.

   [<a id="ref-appDNS">appDNS</a>]      Peterson, J., Kolkman, O., Tschofenig, H., and  B.
                 Aboba, "Architectural Considerations on Application
                 Features in the DNS", Work in Progress, July 2012.

   [<a id="ref-BA11">BA11</a>]        Bhatti, S. and R. Atkinson, "Reducing DNS Caching",
                 Proceedings of IEEE Global Internet Symposium (GI2011),
                 Shanghai, P.R. China, 15 Apr 2011.

   [<a id="ref-BA12">BA12</a>]        Bhatti, S. and R. Atkinson, "Secure &amp; Agile Wide-area
                 Virtual Machine Mobility", Proceedings of IEEE Military
                 Communications Conference (MILCOM), Orlando, FL, USA,
                 Oct 2012.

   [<a id="ref-BAK11">BAK11</a>]       Bhatti, S., Atkinson, R., and J. Klemets, "Integrating
                 Challenged Networks", Proceedings of IEEE Military
                 Communications Conference (MILCOM), IEEE, Baltimore,
                 MD, USA, Nov 2011.

   [<a id="ref-BRDP11">BRDP11</a>]      Boot, T. and A. Holtzer, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22BRDP+Framework%22'>"BRDP Framework"</a>, Work in
                 Progress, January 2011.



<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


   [<a id="ref-DMS04">DMS04</a>]       Dingledine, R., Mathewson, N., and P. Syverson, "Tor:
                 the second-generation onion router", Proceedings of
                 13th USENIX Security Symposium, USENIX Association, San
                 Diego, CA, USA, 2004.

   [<a id="ref-IEEE04">IEEE04</a>]      "IEEE 802.1D - IEEE Standard for Local and Metropolitan
                 Area Networks, Media Access Control (MAC) Bridges",
                 IEEE Standards Association, New York, NY, USA, 9 June
                 2004.  Print: ISBN 0-7381-3881-5 SH95213.  PDF: ISBN
                 0-7381-3982-3 SS95213.

   [<a id="ref-LABH06">LABH06</a>]      Atkinson, R., Lad, M., Bhatti, S., and S. Hailes, "A
                 Proposal for Coalition Networking in Dynamic
                 Operational Environments", Proceedings of IEEE Military
                 Communications Conference (MILCOM), IEEE, Washington,
                 DC, USA, Nov 2006.

   [<a id="ref-mDNS11">mDNS11</a>]      Cheshire, S. and M. Krochmal, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22Multicast+DNS%22'>"Multicast DNS"</a>, Work in
                 Progress, December 2011.

   [<a id="ref-RAB09">RAB09</a>]       Rehunathan, D., Atkinson, R., and S. Bhatti, "Enabling
                 Mobile Networks Through Secure Naming", Proceedings of
                 IEEE Military Communications Conference (MILCOM), IEEE,
                 Boston, MA, USA, Oct 2009.

   [<a id="ref-RB10">RB10</a>]        Rehunathan, D. and S. Bhatti, "A Comparative Assessment
                 of Routing for Mobile Networks", Proceedings of 6th
                 IEEE International Conference on Wireless and Mobile
                 Computing Networking and Communications (WiMob), IEEE,
                 Niagara Falls, ON, Canada, Oct 2010.

   [<a id="ref-RFC4193">RFC4193</a>]     Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
                 Addresses", <a href="./rfc4193">RFC 4193</a>, October 2005.

   [<a id="ref-RFC6296">RFC6296</a>]     Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network
                 Prefix Translation", <a href="./rfc6296">RFC 6296</a>, June 2011.

   [<a id="ref-RSG98">RSG98</a>]       Reed, M., Syverson, P., and D. Goldschlag, "Anonymous
                 Connections and Onion Routing", IEEE Journal on
                 Selected Areas in Communications, Vol. 16, No. 4, IEEE,
                 Piscataway, NJ, USA, May 1998.










<span class="grey">Atkinson &amp; Bhatti             Experimental                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6748">RFC 6748</a>                        ILNP ADV                   November 2012</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Acknowledgements</span>

   Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa,
   Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt,
   Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson,
   Robin Whittle, and John Wroclawski (in alphabetical order) provided
   review and feedback on earlier versions of this document.  Steve
   Blake provided an especially thorough review of an early version of
   the entire ILNP document set, which was extremely helpful.  We also
   wish to thank the anonymous reviewers of the various ILNP papers for
   their feedback.

   Roy Arends provided expert guidance on technical and procedural
   aspects of DNS issues.

Authors' Addresses

   RJ Atkinson
   Consultant
   San Jose, CA 95125
   USA

   EMail: rja.lists@gmail.com


   SN Bhatti
   School of Computer Science
   University of St Andrews
   North Haugh, St Andrews
   Fife  KY16 9SX
   Scotland, UK

   EMail: saleem@cs.st-andrews.ac.uk


















Atkinson &amp; Bhatti             Experimental                     [Page 37]
</pre>