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 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 & 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 & 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 & 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=""Report from the IAB Workshop on Routing and Addressing"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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=""Site- Controlled Secure Multi-Homing and Traffic Engineering For IP"">ABH09a</a>].
<span class="grey">Atkinson & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">RFC6740</a>] is the main architectural description of ILNP, including
the concept of operations.
b) [<a href="./rfc6741" title=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">RFC6741</a>] describes engineering and implementation considerations
that are common to both ILNPv4 and ILNPv6.
c) [<a href="./rfc6742" title=""DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)"">RFC6742</a>] defines additional DNS resource records that support
ILNP.
d) [<a href="./rfc6743" title=""ICMPv6 Locator Update Message"">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 & 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=""IPv6 Nonce Destination Option for the Identifier-Locator Network Protocol for IPv6 (ILNPv6)"">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=""ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)"">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=""IPv4 Options for the Identifier-Locator Network Protocol (ILNP)"">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=""Address Resolution Protocol (ARP) Extension for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)"">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=""Key words for use in RFCs to Indicate Requirement Levels"">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=""Traditional IP Network Address Translator (Traditional NAT)"">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=""Address Allocation for Private Internets"">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=""Address Allocation for Private Internets"">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=""Unique Local IPv6 Unicast Addresses"">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 & 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=""Address Allocation for Private Internets"">RFC1918</a>], is still desirable for
IPv6 [<a href="./rfc5902" title=""IAB Thoughts on IPv6 Network Address Translation"">RFC5902</a>], even though there is debate about the efficacy of
such an approach [<a href="./rfc4864" title=""Local Network Protection for IPv6"">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=""Reflections on Internet Transparency"">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=""IPv6-to-IPv6 Network Prefix Translation"">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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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=""Reducing DNS Caching"">BA11</a>] [<a href="#ref-LABH06" title=""A Proposal for Coalition Networking in Dynamic Operational Environments"">LABH06</a>] [<a href="#ref-ABH07a" title=""Mobility as an Integrated Service Through the Use of Naming"">ABH07a</a>] [<a href="#ref-ABH07b" title=""A Proposal for Unifying Mobility with Multi-Homing, NAT, & Security"">ABH07b</a>] [<a href="#ref-ABH08a" title=""Mobility Through Naming: Impact on DNS"">ABH08a</a>]
[<a href="#ref-ABH08b" title=""Harmonised Resilience, Security, and Mobility Capability for IP"">ABH08b</a>] [<a href="#ref-ABH09a" title=""Site- Controlled Secure Multi-Homing and Traffic Engineering For IP"">ABH09a</a>] [<a href="#ref-ABH09b" title=""ILNP: Mobility, Multi-Homing, Localised Addressing and Security Through Naming"">ABH09b</a>] [<a href="#ref-RAB09" title=""Enabling Mobile Networks Through Secure Naming"">RAB09</a>] [<a href="#ref-RB10" title=""A Comparative Assessment of Routing for Mobile Networks"">RB10</a>] [<a href="#ref-ABH10" title=""Evolving the Internet Architecture Through Naming"">ABH10</a>] [<a href="#ref-BAK11" title=""Integrating Challenged Networks"">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 & 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=""Unique Local IPv6 Unicast Addresses"">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:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_L, L_CN> --- (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:
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (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 & 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:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_1> --- (2a)
and the SBR would rewrite the Locator value on the ingress packet
before forwarding the packet on its internal interface:
<UDP: I_CN, I_H, P_CN, P_H><ILNP: L_CN, L_L> --- (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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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 & 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=""IPv6 Address Assignment to End Sites"">RFC6177</a>] and ILNPv4 [<a href="./rfc4632" title=""Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan"">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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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) |
+---+---------------------+-----------+-------------------------+
+<-------- L_pp --------->+<- L_ss -->+
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=""IPv6 Address Assignment to End Sites"">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 & 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) |
+------------------------+----------+
+<------- L_pp --------->+<- L_ss ->+
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=""Architectural Considerations on Application Features in the DNS"">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 & 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=""IEEE 802.1D - IEEE Standard for Local and Metropolitan Area Networks, Media Access Control (MAC) Bridges"">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=""Default Address Selection for Internet Protocol version 6 (IPv6)"">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=""DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)"">RFC6742</a>]
[<a href="./rfc6743" title=""ICMPv6 Locator Update Message"">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 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=""Default Address Selection for Internet Protocol version 6 (IPv6)"">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=""Site- Controlled Secure Multi-Homing and Traffic Engineering For IP"">ABH09a</a>]. However, the details for this are left for further study,
and overall, the rules defined in [<a href="./rfc3484" title=""Default Address Selection for Internet Protocol version 6 (IPv6)"">RFC3484</a>] and [<a href="./rfc6724">RFC6724</a>] cannot be
applied directly to ILNPv6 nodes.
<span class="grey">Atkinson & 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=""Multicast DNS"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""DNS Resource Records for the Identifier-Locator Network Protocol (ILNP)"">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 & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">RFC6740</a>] and [<a href="./rfc6741" title=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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 6
of RFC 4787</a> [<a href="./rfc4787" title=""Network Address Translation (NAT) Behavioral Requirements for Unicast UDP"">RFC4787</a>].)
<span class="grey">Atkinson & 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 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=""BRDP Framework"">BRDP11</a>].
<span class="grey">Atkinson & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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 & 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=""ICMP Locator Update Message for the Identifier-Locator Network Protocol for IPv4 (ILNPv4)"">RFC6745</a>] [<a href="./rfc6743" title=""ICMPv6 Locator Update Message"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">RFC6740</a>], end-to-end transport-layer session state
invariance is maintained.
<span class="grey">Atkinson & 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 & 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=""Reducing DNS Caching"">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 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 & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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 & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">RFC6740</a>].
<span class="grey">Atkinson & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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 & 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 & 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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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 & 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 & 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=""Secure & Agile Wide-area Virtual Machine Mobility"">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 & 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)):
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_1, L_CN> --- (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 & 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 & 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).
<UDP: I_V, I_CN, P_V, P_CN><ILNP: L_2, L_CN> --- (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 & 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=""Tor: the second-generation onion router"">DMS04</a>] [<a href="#ref-RSG98" title=""Anonymous Connections and Onion Routing"">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.
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_1, L_CN> --- (7a)
v
|
+--+--+
| | src=[I_H, L_1], L_X --- (7b)
| LRR | dst=[I_H, L_X], L_1 --- (7c)
| |
+--+--+
|
v
<UDP: I_H, I_CN, P_H, P_CN><ILNP: L_X, L_CN> --- (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 & 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 & 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=""Identifier-Locator Network Protocol (ILNP) Engineering and Implementation Considerations"">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=""Identifier-Locator Network Protocol (ILNP) Architectural Description"">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=""Tor: the second-generation onion router"">DMS04</a>] and [<a href="#ref-RSG98" title=""Anonymous Connections and Onion Routing"">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 & 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 & 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, &
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 & 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 & 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&q=inurl:draft-+%22BRDP+Framework%22'>"BRDP Framework"</a>, Work in
Progress, January 2011.
<span class="grey">Atkinson & 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&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 & 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 & Bhatti Experimental [Page 37]
</pre>
|