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
|
Network Working Group C. Partridge
Request for Comments: 1726 BBN Systems and Technologies
Category: Informational F. Kastenholz
FTP Software
December 1994
Technical Criteria for Choosing
IP The Next Generation (IPng)
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the IPng
Area of any ideas expressed within. Comments should be submitted to
the big-internet@munnari.oz.au mailing list. This RFC specifies
criteria related to mobility for consideration in design and
selection of the Next Generation of IP.
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 2
2. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Note on Terminology . . . . . . . . . . . . . . . . . . . 4
4. General Principles. . . . . . . . . . . . . . . . . . . . 4
4.1 Architectural Simplicity. . . . . . . . . . . . . . . . . 4
4.2 One Protocol to Bind Them All . . . . . . . . . . . . . . 4
4.3 Live Long . . . . . . . . . . . . . . . . . . . . . . . . 5
4.4 Live Long AND Prosper . . . . . . . . . . . . . . . . . . 5
4.5 Co-operative Anarchy. . . . . . . . . . . . . . . . . . . 5
5. Criteria. . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 Topological Flexibility . . . . . . . . . . . . . . . . . 8
5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Robust Service. . . . . . . . . . . . . . . . . . . . . . 10
5.5 Transition. . . . . . . . . . . . . . . . . . . . . . . . 12
5.6 Media Independence. . . . . . . . . . . . . . . . . . . . 13
5.7 Unreliable Datagram Service . . . . . . . . . . . . . . . 15
5.8 Configuration, Administration, and Operation. . . . . . . 16
5.9 Secure Operation. . . . . . . . . . . . . . . . . . . . . 17
5.10 Unique Naming . . . . . . . . . . . . . . . . . . . . . . 18
5.11 Access. . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.12 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 20
Partridge and Kastenholz [Page 1]
RFC 1726 IPng Technical Criteria December 1994
5.13 Extensibility . . . . . . . . . . . . . . . . . . . . . . 21
5.13.1 Algorithms. . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.2 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.13.3 Data Structures . . . . . . . . . . . . . . . . . . . . . 22
5.13.4 Packets . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.14 Network Service . . . . . . . . . . . . . . . . . . . . . 22
5.15 Support for Mobility. . . . . . . . . . . . . . . . . . . 24
5.16 Control Protocol. . . . . . . . . . . . . . . . . . . . . 25
5.17 Private Networks. . . . . . . . . . . . . . . . . . . . . 25
6. Things We Chose Not to Require. . . . . . . . . . . . . . 26
6.1 Fragmentation . . . . . . . . . . . . . . . . . . . . . . 26
6.2 IP Header Checksum. . . . . . . . . . . . . . . . . . . . 26
6.3 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4 Network Management. . . . . . . . . . . . . . . . . . . . 27
6.5 Accounting. . . . . . . . . . . . . . . . . . . . . . . . 27
6.6 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.6.1 Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.2 Policy. . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.3 QOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.4 Feedback. . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.5 Stability . . . . . . . . . . . . . . . . . . . . . . . . 28
6.6.6 Multicast . . . . . . . . . . . . . . . . . . . . . . . . 29
7. References . . . . . . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . 30
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . 30
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . 31
1. Introduction
This version of this memo was commissioned by the IPng area of the
IETF in order to define a set of criteria to be used in evaluating
the protocols being proposed for adoption as the next generation of
IP.
The criteria presented here were culled from several sources,
including "IP Version 7" [1], "IESG Deliberations on Routing and
Addressing" [2], "Towards the Future Internet Architecture" [3], the
IPng Requirements BOF held at the Washington D.C. IETF Meeting in
December of 1992, the IPng Working Group meeting at the Seattle IETF
meeting in March 1994, the discussions held on the Big-Internet
mailing list (big-internet@munnari.oz.au, send requests to join to
big-internet-request@munnari.oz.au), discussions with the IPng Area
Directors and Directorate, and the mailing lists devoted to the
individual IPng efforts.
This document presumes that a new IP-layer protocol is actually
desired. There is some discussion in the community as to whether we
can extend the life of IPv4 for a significant amount of time by
Partridge and Kastenholz [Page 2]
RFC 1726 IPng Technical Criteria December 1994
better engineering of, e.g., routing protocols, or we should develop
IPng now. This question is not addressed in this document.
We would like to gratefully acknowledge the assistance of literally
hundreds of people who shared their views and insights with us.
However, this memo is solely the personal opinion of the authors and
in no way represents, nor should it be construed as representing, the
opinion of the ISOC, the IAB, the IRTF, the IESG, the IETF, the
Internet community as a whole, nor the authors' respective employers.
2. Goals
We believe that by developing a list of criteria for evaluating
proposals for IP The Next Generation (IPng), the IETF will make it
easier for developers of proposals to prioritize their work and
efforts and make reasoned choices as to where they should spend
relatively more and less time. Furthermore, a list of criteria may
help the IETF community determine which proposals are serious
contenders for a next generation IP, and which proposals are
insufficient to the task. Note that these criteria are probably not
sufficient to make final decisions about which proposal is best.
Questions such as whether to trade a little performance (e.g.,
packets per second routed) for slightly more functionality (e.g.,
more flexible routing) cannot be easily addressed by a simple list of
criteria. However, at minimum, we believe that protocols that meet
these criteria are capable of serving as the future IPng.
This set of criteria originally began as an ordered list, with the
goal of ranking the importance of various criteria. Eventually, the
layout evolved into the current form, where each criterion was
presented without weighting, but a time frame, indicating
approximately when a specific criterion, or feature of a criterion,
should be available was added to the specification.
We have attempted to state the criteria in the form of goals or
requirements and not demand specific engineering solutions. For
example, there has been talk in the community of making route
aggregation a requirement. We believe that route aggregation is not,
in and of itself, a requirement but rather one part of a solution to
the real problem of scaling to some very large, complex topology.
Therefore, route aggregation is NOT listed as a requirement; instead,
the more general functional goal of having the routing scale is
listed instead of the particular mechanism of route aggregation.
In determining the relative timing of the various criteria, we have
had two guiding principles. First, IPng must offer an internetwork
service akin to that of IPv4, but improved to handle the well-known
and widely-understood problems of scaling the Internet architecture
Partridge and Kastenholz [Page 3]
RFC 1726 IPng Technical Criteria December 1994
to more end-points and an ever increasing range of bandwidths.
Second, it must be desirable for users and network managers to
upgrade their equipment to support IPng. At a minimum, this second
point implies that there must be a straightforward way to transition
systems from IPv4 to IPng. But it also strongly suggests that IPng
should offer features that IPv4 does not; new features provide a
motivation to deploy IPng more quickly.
3. Note on Terminology
The existing proposals tend distinguish between end-point
identification of, e.g., individual hosts, and topological addresses
of network attachment points. In this memo we do not make that
distinction. We use the term "address" as it is currently used in
IPv4; i.e., for both the identification of a particular endpoint or
host AND as the topological address of a point on the network. We
presume that if the endpoint/ address split remains, the proposals
will make the proper distinctions with respect to the criteria
enumerated below.
4. General Principles
4.1 Architectural Simplicity
In anything at all, perfection is finally attained not
when there is no longer anything to add, but when there
is no longer anything to take away.
Antoine de Saint-Exupery
We believe that many communications functions are more appropriately
performed at protocol layers other than the IP layer. We see
protocol stacks as hourglass-shaped, with IPng in the middle, or
waist, of the hourglass. As such, essentially all higher-layer
protocols make use of and rely upon IPng. Similarly IPng, by virtue
of its position in the "protocol hourglass" encompasses a wide
variety of lower-layer protocols. When IPng does not perform a
particular function or provide a certain service, it should not get
in the way of the other elements of the protocol stack which may well
wish to perform the function.
4.2 One Protocol to Bind Them All
One of the most important aspects of The Internet is that it provides
global IP-layer connectivity. The IP layer provides the point of
commonality among all of the nodes on the Internet. In effect, the
main goal of the Internet is to provide an IP Connectivity Service to
all who wish it.
Partridge and Kastenholz [Page 4]
RFC 1726 IPng Technical Criteria December 1994
This does NOT say that the Internet is a One-Protocol Internet. The
Internet is today, and shall remain in the future, a Multi-Protocol
Internet. Multi-Protocol operations are required to allow for
continued testing, experimentation, and development and because
service providers' customers clearly want to be able to run protocols
such as CLNP, DECNET, and Novell over their Internet connections.
4.3 Live Long
It is very difficult to change a protocol as central to the workings
of the Internet as IP. Even more problematic is changing such a
protocol frequently. This simply can not be done. We believe that it
is impossible to expect the community to make significant, non-
backward compatible changes to the IP layer more often than once
every 10-15 years. In order to be conservative, we strongly urge
protocol developers to consider what the Internet will look like in
20 years and design their protocols to fit that vision.
As a data point, the SNMP community has had great difficulty moving
from SNMPv1 to SNMPv2. Frequent changes in software are hard.
4.4 Live Long AND Prosper
We believe that simply allowing for bigger addresses and more
efficient routing is not enough of a benefit to encourage vendors,
service providers, and users to switch to IPng, with its attendant
disruptions of service, etc. These problems can be solved much more
simply with faster routers, balkanization of the Internet address
space, and other hacks.
We believe that there must be positive functional or operational
benefits to switching to IPng.
In other words, IPng must be able to live for a long time AND it must
allow the Internet to prosper and to grow to serve new applications
and user needs.
4.5 Co-operative Anarchy
A major contributor to the Internet's success is the fact that there
is no single, centralized, point of control or promulgator of policy
for the entire network. This allows individual constituents of the
network to tailor their own networks, environments, and policies to
suit their own needs. The individual constituents must cooperate
only to the degree necessary to ensure that they interoperate.
Partridge and Kastenholz [Page 5]
RFC 1726 IPng Technical Criteria December 1994
We believe that this decentralized and decoupled nature of the
Internet must be preserved. Only a minimum amount of centralization
or forced cooperation will be tolerated by the community as a whole.
We also believe that there are some tangible benefits to this
decoupled nature. For example,
* It is easier to experiment with new protocols and services and then
roll out intermediate and final results in a controlled fashion.
* By eliminating a single point of control, a single point of failure
is also eliminated, making it much less likely that the entire
network will fail.
* It allows the administrative tasks for the network to be more
widely distributed.
An example of the benefits of this "Cooperative Anarchy" can be seen
in the benefits derived from using the Domain Naming System over the
original HOSTS.TXT system.
5. Criteria
This section enumerates the criteria against which we suggest the IP
The Next Generation proposals be evaluated.
Each criterion is presented in its own section. The first paragraph
of each section is a short, one or two sentence statement of the
criterion. Additional paragraphs then explain the criterion in more
detail, clarify what it does and does not say and provide some
indication of its relative importance.
Also, each criterion includes a subsection called "Time Frame". This
is intended to give a rough indication of when the authors believe
that the particular criterion will become "important". We believe
that if an element of technology is significant enough to include in
this document then we probably understand the technology enough to
predict how important that technology will be. In general, these
time frames indicate that, within the desired time frame, we should
be able to get an understanding of how the feature will be added to a
protocol, perhaps after discussions with the engineers doing the
development. Time Frame is not a deployment schedule since
deployment schedules depend on non-technical issues, such as vendors
determining whether a market exists, users fitting new releases into
their systems, and so on.
Partridge and Kastenholz [Page 6]
RFC 1726 IPng Technical Criteria December 1994
5.1 Scale
CRITERION
The IPng Protocol must scale to allow the identification and
addressing of at least 10**12 end systems (and preferably much
more). The IPng Protocol, and its associated routing protocols
and architecture must allow for at least 10**9 individual networks
(and preferably more). The routing schemes must scale at a rate
that is less than the square root of the number of constituent
networks [10].
DISCUSSION
The initial, motivating, purpose of the IPng effort is to allow
the Internet to grow beyond the size constraints imposed by the
current IPv4 addressing and routing technologies.
Both aspects of scaling are important. If we can't route then
connecting all these hosts is worthless, but without connected
hosts, there's no point in routing, so we must scale in both
directions.
In any proposal, particular attention must be paid to describing
the routing hierarchy, how the routing and addressing will be
organized, how different layers of the routing interact, and the
relationship between addressing and routing.
Particular attention must be paid to describing what happens when
the size of the network approaches these limits. How are network,
forwarding, and routing performance affected? Does performance
fall off or does the network simply stop as the limit is neared.
This criterion is the essential problem motivating the transition
to IPng. If the proposed protocol does not satisfy this criteria,
there is no point in considering it.
We note that one of the white papers solicited for the IPng
process [5] indicates that 10**12 end nodes is a reasonable
estimate based on the expected number of homes in the world and
adding two orders of magnitude for "safety". However, this white
paper treats each home in the world as an end-node of a world-wide
Internet. We believe that each home in the world will in fact be
a network of the world-wide Internet. Therefore, if we take [5]'s
derivation of 10**12 as accurate, and change their assumption that
a home will be an end-node to a home being a network, we may
expect that there will be the need to support at least 10**12
networks, with the possibility of supporting up to 10**15 end-
nodes.
Partridge and Kastenholz [Page 7]
RFC 1726 IPng Technical Criteria December 1994
Time Frame
Any IPng proposal should be able to show immediately that it has
an architecture for the needed routing protocols, addressing
schemes, abstraction techniques, algorithms, data structures, and
so on that can support growth to the required scales.
Actual development, specification, and deployment of the needed
protocols can be deferred until IPng deployment has extended far
enough to require such protocols. A proposed IPng should be able
to demonstrate ahead of time that it can scale as needed.
5.2 Topological Flexibility
CRITERION
The routing architecture and protocols of IPng must allow for many
different network topologies. The routing architecture and
protocols must not assume that the network's physical structure is
a tree.
DISCUSSION
As the Internet becomes ever more global and ubiquitous, it will
develop new and different topologies. We already see cases where
the network hierarchy is very "broad" with many subnetworks, each
with only a few hosts and where it is very "narrow", with few
subnetworks each with many hosts. We can expect these and other
topological forms in the future. Furthermore, since we expect
that IPng will allow for many more levels of hierarchy than are
allowed under IPv4, we can expect very "tall" and very "short"
topologies as well.
Constituent organizations of the Internet should be allowed to
structure their internal topologies in any manner they see fit.
Within reasonable implementation limits, organizations should be
allowed to structure their addressing in any manner. We
specifically wish to point out that if the network's topology or
addressing is hierarchical, constituent organizations should be
able to allocate to themselves as many levels of hierarchy as they
wish.
It is very possible that the diameter of the Internet will grow to
be extremely large; perhaps larger than 256 hops.
Neither the current, nor the future, Internet will be physically
structured as a tree, nor can we assume that connectivity can
occur only between certain points in the graph. The routing and
addressing architectures must allow for multiply connected
networks and be able to utilize multiple paths for any reason,
including redundancy, load sharing, type- and quality-of-service
Partridge and Kastenholz [Page 8]
RFC 1726 IPng Technical Criteria December 1994
differentiation.
Time Frame
We believe that Topological Flexibility is an inherent element of
a protocol and therefore should be immediately demonstrable in an
IPng proposal.
5.3 Performance
CRITERION
A state of the art, commercial grade router must be able to
process and forward IPng traffic at speeds capable of fully
utilizing common, commercially available, high-speed media at the
time. Furthermore, at a minimum, a host must be able to achieve
data transfer rates with IPng comparable to the rates achieved
with IPv4, using similar levels of host resources.
DISCUSSION
Network media speeds are constantly increasing. It is essential
that the Internet's switching elements (routers) be able to keep
up with the media speeds.
We limit this requirement to commercially available routers and
media. If some network site can obtain a particular media
technology "off the shelf", then it should also be able to obtain
the needed routing technology "off the shelf." One can always go
into some laboratory or research center and find newer, faster,
technologies for network media and for routing. We do believe,
however, that IPng should be routable at a speed sufficient to
fully utilize the fastest available media, though that might
require specially built, custom, devices.
We expect that more and more services will be available over the
Internet. It is not unreasonable, therefore, to expect that the
ratio of "local" traffic (i.e., the traffic that stays on one's
local network) to "export" traffic (i.e., traffic destined to or
sourced from a network other than one's own local network) will
change, and the percent of export traffic will increase.
We note that the host performance requirement should not be taken
to imply that IPng need only be as good as IPv4. If an IPng
candidate can achieve better performance with equivalent resources
(or equivalent transfer rates with fewer resources) vis-a-vis IPv4
then so much the better. We also observe that many researchers
believe that a proper IPng router should be capable of routing
IPng traffic over links at speeds that are capable of fully
utilizing an ATM switch on the link.
Partridge and Kastenholz [Page 9]
RFC 1726 IPng Technical Criteria December 1994
Some developments indicate that the use of very high speed point-
to-point connections may become commonplace. In particular, [5]
indicates that OC-3 speeds may be widely used in the Cable TV
Industry and there may be many OC-3 speed lines connecting to
central switching elements.
Processing of the IPng header, and subsequent headers (such as the
transport header), can be made more efficient by aligning fields
on their natural boundaries and making header lengths integral
multiples of typical word lengths (32, 64, and 128 bits have been
suggested) in order to preserve alignment in following headers.
We point out that optimizing the header's fields and lengths only
to today's processors may not be sufficient for the long term.
Processor word and cache-line lengths, and memory widths are
constantly increasing. In doing header optimizations, the
designer should predict word-widths one or two CPU generations
into the future and optimize accordingly. If IPv4 and TCP had been
optimized for processors common when they were designed, they
would be very efficient for 6502s and Z-80s.
Time Frame
An IPng proposal must provide a plausible argument of how it will
scale up in performance. (Obviously no one can completely predict
the future, but the idea is to illustrate that if technology
trends in processor performance and memory performance continue,
and perhaps using techniques like parallelism, there is reason to
believe the proposed IPng will scale as technology scales).
5.4 Robust Service
CRITERION
The network service and its associated routing and control
protocols must be robust.
DISCUSSION
Murphy's Law applies to networking. Any proposed IPng protocol
must be well-behaved in the face of malformed packets, mis-
information, and occasional failures of links, routers and hosts.
IPng should perform gracefully in response to willful management
and configuration mistakes (i.e., service outages should be
minimized).
Putting this requirement another way, IPng must make it possible
to continue the Internet tradition of being conservative in what
is sent, but liberal in what one is willing to receive.
Partridge and Kastenholz [Page 10]
RFC 1726 IPng Technical Criteria December 1994
We note that IPv4 is reasonably robust and any proposed IPng must
be at least as robust as IPv4.
Hostile attacks on the network layer and Byzantine failure modes
must be dealt with in a safe and graceful manner.
We note that Robust Service is, in some form, a part of security
and vice-versa.
The detrimental effects of failures, errors, buggy
implementations, and misconfigurations must be localized as much
as possible. For example, misconfiguring a workstation's IP
Address should not break the routing protocols. in the event of
misconfigurations, IPng must to be able to detect and at least
warn, if not work around, any misconfigurations.
Due to its size, complexity, decentralized administration, error-
prone users and administrators, and so on, The Internet is a very
hostile environment. If a protocol can not be used in such a
hostile environment then it is not suitable for use in the
Internet.
Some predictions have been made that, as the Internet grows and as
more and more technically less-sophisticated sites get connected,
there will be more failures in the network. These failures may be
a combination of simple size; if the size of the network goes up
by a factor of n, then the total number of failures in the network
can be expected to increase by some function of n. Also, as the
network's users become less sophisticated, it can be assumed that
they will make more, innocent and well meaning, mistakes, either
in configuration or use of their systems.
The IPng protocols should be able to continue operating in an
environment that suffers more, total, outages than we are
currently used to. Similarly, the protocols must protect the
general population from errors (either of omission or commission)
made by individual users and sites.
Time Frame
We believe that the elements of Robust Service should be available
immediately in the protocol with two exceptions.
The security aspects of Robust Service are, in fact, described
elsewhere in this document.
Partridge and Kastenholz [Page 11]
RFC 1726 IPng Technical Criteria December 1994
Protection against Byzantine failure modes is not needed
immediately. A proposed architecture for it should be done
immediately. Prototype development should be completed in 12-18
months, with final deployment as needed.
5.5 Transition
CRITERION
The protocol must have a straightforward transition plan from the
current IPv4.
DISCUSSION
A smooth, orderly, transition from IPv4 to IPng is needed. If we
can't transition to the new protocol, then no matter how wonderful
it is, we'll never get to it.
We believe that it is not possible to have a "flag-day" form of
transition in which all hosts and routers must change over at
once. The size, complexity, and distributed administration of the
Internet make such a cutover impossible.
Rather, IPng will need to co-exist with IPv4 for some period of
time. There are a number of ways to achieve this co-existence
such as requiring hosts to support two stacks, converting between
protocols, or using backward compatible extensions to IPv4. Each
scheme has its strengths and weaknesses, which have to be weighed.
Furthermore, we note that, in all probability, there will be IPv4
hosts on the Internet effectively forever. IPng must provide
mechanisms to allow these hosts to communicate, even after IPng
has become the dominant network layer protocol in the Internet.
The absence of a rational and well-defined transition plan is not
acceptable. Indeed, the difficulty of running a network that is
transitioning from IPv4 to IPng must be minimized. (A good target
is that running a mixed IPv4-IPng network should be no more and
preferably less difficult than running IPv4 in parallel with
existing non-IP protocols).
Furthermore, a network in transition must still be robust. IPng
schemes which maximize stability and connectivity in mixed IPv4-
IPng networks are preferred.
Finally, IPng is expected to evolve over time and therefore, it
must be possible to have multiple versions of IPng, some in
production use, some in experimental, developmental, or evaluation
use, to coexist on the network. Transition plans must address
this issue.
Partridge and Kastenholz [Page 12]
RFC 1726 IPng Technical Criteria December 1994
The transition plan must address the following general areas of
the Internet's infrastructure:
Host Protocols and Software
Router Protocols and Software
Security and Authentication
Domain Name System
Network Management
Operations Tools (e.g., Ping and Traceroute)
Operations and Administration procedures
The impact on protocols which use IP addresses as data (e.g., DNS,
distributed file systems, SNMP and FTP) must be specifically
addressed.
The transition plan should address the issue of cost distribution.
That is, it should identify what tasks are required of the service
providers, of the end users, of the backbones and so on.
Time Frame
A transition plan is required immediately.
5.6 Media Independence
CRITERION
The protocol must work across an internetwork of many different
LAN, MAN, and WAN media, with individual link speeds ranging from
a ones-of-bits per second to hundreds of gigabits per second.
Multiple-access and point-to-point media must be supported, as
must media supporting both switched and permanent circuits.
DISCUSSION
The joy of IP is that it works over just about anything. This
generality must be preserved. The ease of adding new
technologies, and ability to continue operating with old
technologies must be maintained.
We believe this range of speed is right for the next twenty years,
though we may wish to require terabit performance at the high-end.
We believe that, at a minimum, media running at 500 gigabits per
second will be commonly available within 10 years. The low end of
the link-speed range is based on the speed of systems like pagers
and ELF (ELF connects to submerged submarines and has a "speed" on
the order of <10 characters per second).
By switched circuits we mean both "permanent" connections such as
X.25 and Frame Relay services AND "temporary" types of dialup
connections similar to today's SLIP and dialup PPP services, and
Partridge and Kastenholz [Page 13]
RFC 1726 IPng Technical Criteria December 1994
perhaps, ATM SVCs. The latter form of connection implies that
dynamic network access (i.e., the ability to unplug a machine,
move it to a different point on the network topology, and plug it
back in, possibly with a changed IPng address) is required. We
note that this is an aspect of mobility.
By work, we mean we have hopes that a stream of IPng datagrams
(whether from one source, or many) can come close to filling the
link at high speeds, but also scales gracefully to low speeds.
Many network media are multi-protocol. It is essential that IPng
be able to peacefully co-exist on such media with other protocols.
Routers and hosts must be able to discriminate among the protocols
that might be present on such a medium. For example, on an
Ethernet, a specific, IPng Ethernet Type value might be called
for; or the old IPv4 Ethernet type is used and the first four
(version number in the old IPv4 header) bits would distinguish
between IPv4 and IPng.
Different media have different MAC address formats and schemes.
It must be possible for a node to dynamically determine the MAC
address of a node given that node's IP address. We explicitly
prohibit using static, manually configured mappings as the
standard approach.
Another aspect of this criterion is that many different MTUs will
be found in an IPng internetwork. An IPng must be able to operate
in such a multi-MTU environment. It must be able to adapt to the
MTUs of the physical media over which it operates. Two possible
techniques for dealing with this are path MTU discovery and
fragmentation and reassembly; other techniques might certainly be
developed.
We note that, as of this writing (mid 1994), ATM seems to be set
to become a major network media technology. Any IPng should be
designed to operate over ATM. However, IPng still must be able to
operate over other, more "traditional" network media.
Furthermore, a host on an ATM network must be able to interoperate
with a host on another, non-ATM, medium, with no more difficulty
or complexity than hosts on different media can interoperate today
using IPv4.
IPng must be able to deal both with "dumb" media, such as we have
today, and newer, more intelligent, media. In particular, IPng
functions must be able to exist harmoniously with lower-layer
realizations of the same, or similar, functions. Routing and
resource management are two areas where designers should pay
particular attention. Some subnetwork technologies may include
Partridge and Kastenholz [Page 14]
RFC 1726 IPng Technical Criteria December 1994
integral accounting and billing capabilities, and IPng must
provide the correct control information to such subnetworks.
Time Frame
Specifications for current media encapsulations (i.e., all
encapsulations that are currently Proposed standards, or higher,
in the IETF) are required immediately. These specifications must
include any auxiliary protocols needed (such as an address
resolution mechanism for Ethernet or the link control protocol for
PPP). A general 'guide' should also be available immediately to
help others develop additional media encapsulations. Other,
newer, encapsulations can be developed as the need becomes
apparent.
Van Jacobson-like header compression should be shown immediately,
as should any other aspects of very-low-speed media. Similarly,
any specific aspects of high-speed media should be shown
immediately.
5.7 Unreliable Datagram Service
CRITERION
The protocol must support an unreliable datagram delivery service.
DISCUSSION
We like IP's datagram service and it seems to work very well. So
we must keep it. In particular, the ability, within IPv4, to send
an independent datagram, without prearrangement, is extremely
valuable (in fact, may be required for some applications such as
SNMP) and must be retained.
Furthermore, the design principle that says that we can take any
datagram and throw it away with no warning or other action, or
take any router and turn it off with no warning, and have datagram
traffic still work, is very powerful. This vastly enhances the
robustness of the network and vastly eases administration and
maintenance of the network. It also vastly simplifies the design
and implementation of software [14].
Furthermore, the Unreliable Datagram Service should support some
minimal level of service; something that is approximately
equivalent to IPv4 service. This has two functions; it eases the
task of IPv4/IPng translating systems in mapping IPv4 traffic to
IPng and vice versa, and it simplifies the task of fitting IPng
into small, limited environments such as boot ROMs.
Time Frame
Unreliable Datagram Service must be available immediately.
Partridge and Kastenholz [Page 15]
RFC 1726 IPng Technical Criteria December 1994
5.8 Configuration, Administration, and Operation
CRITERION
The protocol must permit easy and largely distributed
configuration and operation. Automatic configuration of hosts and
routers is required.
DISCUSSION
People complain that IP is hard to manage. We cannot plug and
play. We must fix that problem.
We do note that fully automated configuration, especially for
large, complex networks, is still a topic of research. Our
concern is mostly for small and medium sized, less complex,
networks; places where the essential knowledge and skills would
not be as readily available.
In dealing with this criterion, address assignment and delegation
procedures and restrictions should be addressed by the proposal.
Furthermore, "ownership" of addresses (e.g., user or service
provider) has recently become a concern and the issue should be
addressed.
We require that a node be able to dynamically obtain all of its
operational, IP-level parameters at boot time via a dynamic
configuration mechanism.
A host must be able to dynamically discover routers on the host's
local network. Ideally, the information which a host learns via
this mechanism would also allow the host to make a rational
selection of which first-hop router to send any given packet to.
IPng must not mandate that users or administrators manually
configure first-hop routers into hosts.
Also, a strength of IPv4 has been its ability to be used on
isolated subnets. IPng hosts must be able to work on networks
without routers present.
Additional elements of this criterion are:
* Ease of address allocation.
* Ease of changing the topology of the network within a particular
routing domain.
* Ease of changing network provider.
* Ease of (re)configuring host/endpoint parameters such as
addressing and identification.
* Ease of (re)configuring router parameters such as addressing and
identification.
Partridge and Kastenholz [Page 16]
RFC 1726 IPng Technical Criteria December 1994
* Address allocation and assignment authority must be delegated as
far 'down' the administrative hierarchy as possible.
The requirements of this section apply only to IPng and its
supporting protocols (such as for routing, address resolution, and
network-layer control). Specifically, as far as IPng is
concerned, we are concerned only with how routers and hosts get
their configuration information.
We note that in general, automatic configuration of hosts is a
large and complex problem and getting the configuration
information into hosts and routers is only one, small, piece of
the problem. A large amount of additional, non-Internet-layer
work is needed in order to be able to do "plug-and-play"
networking. Other aspects of "plug-and-play" networking include
things like: Autoregistration of new nodes with DNS, configuring
security service systems (e.g., Kerberos), setting up email relays
and mail servers, locating network resources, adding entries to
NFS export files, and so on. To a large degree, these
capabilities do not have any dependence on the IPng protocol
(other than, perhaps, the format of addresses).
We require that any IPng proposal not impede or prevent, in any
way, the development of "plug-and-play" network configuration
technologies.
Automatic configuration of network nodes must not prevent users or
administrators from also being able to manually configure their
systems.
Time Frame
A method for plug and play on small subnets is immediately
required.
We believe that this is an extremely critical area for any IPng as
a major complaint of the IP community as a whole is the difficulty
in administering large IP networks. Furthermore, ease of
installation is likely to speed the deployment of IPng.
5.9 Secure Operation
CRITERION
IPng must provide a secure network layer.
DISCUSSION
We need to be sure that we have not created a network that is a
cracker's playground.
Partridge and Kastenholz [Page 17]
RFC 1726 IPng Technical Criteria December 1994
In order to meet the Robustness criterion, some elements of what
is commonly shrugged off as "security" are needed; e.g., to prevent
a villain from injecting bogus routing packets, and destroying the
routing system within the network. This criterion covers those
aspects of security that are not needed to provide the Robustness
criterion.
Another aspect of security is non-repudiation of origin. In order
to adequately support the expected need for simple accounting, we
believe that this is a necessary feature.
In order to safely support requirements of the commercial world,
IPng-level security must have capabilities to prevent
eavesdroppers from monitoring traffic and deducing traffic
patterns. This is particularly important in multi-access networks
such as cable TV networks [5].
Aspects of security at the IP level to be considered include:
* Denial of service protections [6],
* Continuity of operations [6],
* Precedence and preemption [6],
* Ability to allow rule-based access control technologies [6]
* Protection of routing and control-protocol operations [9],
* Authentication of routing information exchanges, packets, data,
and sources (e.g., make sure that the routing packet came from a
router) [9],
* QOS security (i.e., protection against improper use of network-
layer resources, functions, and capabilities),
* Auto-configuration protocol operations in that the host must be
assured that it is getting its information from proper sources,
* Traffic pattern confidentiality is strongly desired by several
communities [9] and [5].
Time Frame
Security should be an integral component of any IPng from the
beginning.
5.10 Unique Naming
CRITERION
IPng must assign all IP-Layer objects in the global, ubiquitous,
Internet unique names. These names may or may not have any
location, topology, or routing significance.
DISCUSSION
We use the term "Name" in this criterion synonymously with the
term "End Point Identifier" as used in the NIMROD proposal, or as
Partridge and Kastenholz [Page 18]
RFC 1726 IPng Technical Criteria December 1994
IP Addresses uniquely identify interfaces/hosts in IPv4. These
names may or may not carry any routing or topology information.
See [11] for more discussion on this topic.
IPng must provide identifiers which are suitable for use as
globally unique, unambiguous, and ubiquitous names for endpoints,
nodes, interfaces, and the like. Every datagram must carry the
identifier of both its source and its destination (or some method
must be available to determine these identifiers, given a
datagram). We believe that this is required in order to support
certain accounting functions.
Other functions and uses of unique names are:
* To uniquely identify endpoints (thus if the unique name and
address are not the same, the TCP pseudo-header should include
the unique name rather than the address)
* To allow endpoints to change topological location on the network
(e.g., migrate) without changing their unique names.
* To give one or more unique names to a node on the network (i.e.,
one node may have multiple unique names)
An identifier must refer to one and only one object while that
object is in existence. Furthermore, after an object ceases to
exist, the identifier should be kept unused long enough to ensure
that any packets containing the identifier have drained out of the
Internet system, and that other references to the identifier have
probably been lost. We note that the term "existence" is as much
an administrative issue as a technical one. For example, if a
workstation is reassigned, given a new IP address and node name,
and attached to a new subnetwork, is it the same object or not.
This does argue for a namespace that is relatively large and
relatively stable.
Time Frame
We see this as a fundamental element of the IP layer and it should
be in the protocol from the beginning.
5.11 Access
CRITERION
The protocols that define IPng, its associated protocols (similar
to ARP and ICMP in IPv4) and the routing protocols (as in OSPF,
BGP, and RIP for IPv4) must be published as standards track RFCs
and must satisfy the requirements specified in RFC1310. These
documents should be as freely available and redistributable as the
IPv4 and related RFCs. There must be no specification-related
licensing fees for implementing or selling IPng software.
Partridge and Kastenholz [Page 19]
RFC 1726 IPng Technical Criteria December 1994
DISCUSSION
An essential aspect of the development of the Internet and its
protocols has been the fact that the protocol specifications are
freely available to anyone who wishes a copy. Beyond simply
minimizing the cost of learning about the technology, the free
access to specifications has made it easy for researchers and
developers to easily incorporate portions of old protocol
specifications in the revised specifications. This type of easy
access to the standards documents is required for IPng.
Time Frame
An IPng and its related protocols must meet these standards for
openness before an IPng can be approved.
5.12 Multicast
CRITERION
The protocol must support both unicast and multicast packet
transmission. Part of the multicast capability is a requirement
to be able to send to "all IP hosts on a given subnetwork".
Dynamic and automatic routing of multicasts is also required.
DISCUSSION
IPv4 has made heavy use of the ability to multicast requests to
all IPv4 hosts on a subnet, especially for autoconfiguration.
This ability must be retained in IPng.
Unfortunately, IPv4 currently uses the local media broadcast
address to multicast to all IP hosts. This behavior is anti-
social in mixed-protocol networks and should be fixed in IPng.
There's no good reason for IPng to send to all hosts on a subnet
when it only wishes to send to all IPng hosts. The protocol must
make allowances for media that do not support true multicasting.
In the past few years, we have begun to deploy support for wide-
area multicast addressing in the Internet, and it has proved
valuable. This capability must not be lost in the transition to
IPng.
The ability to restrict the range of a multicast to specific
networks is also important. Furthermore, it must be possible to
"selectively" multicast packets. That is, it must be possible to
send a multicast to a remote, specific portion or area of the
Internet (such as a specific network or subnetwork) and then have
that multicast limited to just that specific area. Furthermore,
any given network or subnetwork should be capable of supporting
2**16 "local" multicast groups, i.e., groups that are not
propagated to other networks. See [8].
Partridge and Kastenholz [Page 20]
RFC 1726 IPng Technical Criteria December 1994
It should be noted that addressing -- specifically the syntax and
semantics of addresses -- has a great impact on the scalability of
the architecture.
Currently, large-scale multicasts are routed manually through the
Internet. While this is fine for experiments, a "production"
system requires that multicast-routing be dynamic and automatic.
Multicast groups must be able to be created and destroyed, hosts
must be able to join and leave multicast groups and the network
routing infrastructure must be able to locate new multicast groups
and destinations and route traffic to those destinations all
without manual intervention.
Large, topologically dispersed, multicast groups (with up to 10**6
participants) must be supported. Some applications are given in
[8].
Time Frame
Obviously, address formats, algorithms for processing and
interpreting the multicast addresses must be immediately available
in IPng. Broadcast and Multicast transmission/reception of
packets are required immediately. Dynamic routing of multicast
packets must be available within 18 months.
We believe that Multicast Addressing is vital to support future
applications such as remote conferencing. It is also used quite
heavily in the current Internet for things like service location
and routing.
5.13 Extensibility
CRITERION
The protocol must be extensible; it must be able to evolve to meet
the future service needs of the Internet. This evolution must be
achievable without requiring network-wide software upgrades. IPng
is expected to evolve over time. As it evolves, it must be able to
allow different versions to coexist on the same network.
DISCUSSION
We do not today know all of the things that we will want the
Internet to be able to do 10 years from now. At the same time, it
is not reasonable to ask users to transition to a new protocol
with each passing decade. Thus, we believe that it must be
possible to extend IPng to support new services and facilities.
Furthermore, it is essential that any extensions can be
incrementally deployed to only those systems which desire to use
them. Systems upgraded in this fashion must still be able to
communicate with systems which have not been so upgraded.
Partridge and Kastenholz [Page 21]
RFC 1726 IPng Technical Criteria December 1994
There are several aspects to extensibility:
5.13.1 Algorithms
The algorithms used in processing IPng information should be
decoupled from the protocol itself. It should be possible to
change these algorithms without necessarily requiring protocol,
datastructure, or header changes.
5.13.2 Headers
The content of packet headers should be extensible. As more
features and functions are required of IPng, it may be
necessary to add more information to the IPng headers. We note
that for IPv4, the use of options has proven less than entirely
satisfactory since options have tended to be inefficient to
process.
5.13.3 Data Structures
The fundamental data structures of IPng should not be bound
with the other elements of the protocol. E.g., things like
address formats should not be intimately tied with the routing
and forwarding algorithms in the way that the IPv4 address
class mechanism was tied to IPv4 routing and forwarding.
5.13.4 Packets
It should be possible to add additional packet-types to IPng.
These could be for, _e._g., new control and/or monitoring
operations.
We note that, everything else being equal, having larger,
oversized, number spaces is preferable to having number spaces
that are "just large enough". Larger spaces afford more
flexibility on the part of network designers and operators and
allow for further experimentation on the part of the scientists,
engineers, and developers. See [7].
Time Frame
A framework showing mechanisms for extending the protocol must be
provided immediately.
5.14 Network Service
CRITERION
The protocol must allow the network (routers, intelligent media,
hosts, and so on) to associate packets with particular service
classes and provide them with the services specified by those
classes.
Partridge and Kastenholz [Page 22]
RFC 1726 IPng Technical Criteria December 1994
DISCUSSION
For many reasons, such as accounting, security and multimedia, it
is desirable to treat different packets differently in the
network.
For example, multimedia is now on our desktop and will be an
essential part of future networking. So we have to find ways to
support it; and a failure to support it may mean users choose to
use protocols other than IPng.
The IETF multicasts have shown that we can currently support
multimedia over internetworks with some hitches. If the network
can be guaranteed to provide the necessary service levels for this
traffic, we will dramatically increase its success.
This criterion includes features such as policy-based routing,
flows, resource reservation, network service technologies, type-
of-service and quality-of-service and so on.
In order to properly support commercial provision and use of
Internetwork service, and account for the use of these services
(i.e., support the economic principle of "value paid for value
received") it must be possible to obtain guarantees of service
levels. Similarly, if the network can not support a previously
guaranteed service level, it must report this to those to whom it
guaranteed the service.
Network service provisions must be secure. The network-layer
security must generally prevent one host from surreptitiously
obtaining or disrupting the use of resources which another host
has validly acquired. (Some security failures are acceptable, but
the failure rate must be very low and the rate should be
quantifiable).
One of the parameters of network service that may be requested
must be cost-based.
As far as possible, given the limitations of underlying media and
IP's model of a robust internet datagram service, real-time,
mission-critical applications must be supported by IPng [6].
Users must be able to confirm that they are, in fact, getting the
services that they have requested.
Time Frame
This should be available within 24 months.
Partridge and Kastenholz [Page 23]
RFC 1726 IPng Technical Criteria December 1994
5.15 Support for Mobility
CRITERION
The protocol must support mobile hosts, networks and
internetworks.
DISCUSSION
Again, mobility is becoming increasingly important. Look at the
portables that everyone is carrying. Note the strength of the
Apple commercial showing someone automatically connecting up her
Powerbook to her computer back in the office. There have been a
number of pilot projects showing ways to support mobility in IPv4.
All have some drawbacks. But like network service grades, if we
can support mobility, IPng will have features that will encourage
transition.
We use an encompassing definition of "mobility" here. Mobility
typically means one of two things to people: 1) Hosts that
physically move and remain connected (via some wireless datalink)
with sessions and transport-layer connections remaining 'open' or
'active' and 2) Disconnecting a host from one spot in the network,
connecting it back in another arbitrary spot and continuing to
work. Both forms are required.
Reference [6] discusses possible future use of IP-based networks
in the US Navy's ships, planes, and shore installations. Their
basic model is that each ship, plane and shore installation
represents at least one IP network. The ship- and plane-based
networks, obviously, are mobile as these craft move around the
world. Furthermore, most, if not all, Naval surface combatants
carry some aircraft (at a minimum, a helicopter or two). So, not
only must there be mobile networks (the ships that move around),
but there must be mobile internetworks: the ships carrying the
aircraft where each aircraft has its own network, which is
connected to the ship's network and the whole thing is moving.
There is also the requirement for dynamic mobility; a plane might
take off from aircraft carrier A and land on carrier B so it
obviously would want to "connect" to B's network. This situation
might be even more complex since the plane might wish to retain
connectivity to its "home" network; that is, the plane might
remain connected to the ship-borne networks of both aircraft
carriers, A and B.
These requirements are not limited to just the navy. They apply
to the civilian and commercial worlds as well. For example, in
civil airliners, commercial cargo and passenger ships, trains,
cars and so on.
Partridge and Kastenholz [Page 24]
RFC 1726 IPng Technical Criteria December 1994
Time Frame
The mobility algorithms are stabilizing and we would hope to see
an IPng mobility framework within a year.
5.16 Control Protocol
CRITERION
The protocol must include elementary support for testing and
debugging networks.
DISCUSSION
An important feature of IPv4 is the ICMP and its debugging,
support, and control features. Specific ICMP messages that have
proven extraordinarily useful within IPv4 are Echo Request/Reply
(a.k.a ping), Destination Unreachable and Redirect. Functions
similar to these should be in IPng.
This criterion explicitly does not concern itself with
configuration related messages of ICMP. We believe that these are
adequately covered by the configuration criterion in this memo.
One limitation of today's ICMP that should be fixed in IPng's
control protocol is that more than just the IPng header plus 64
bits of a failed datagram should be returned in the error message.
In some situations, this is too little to carry all the critical
protocol information that indicates why a datagram failed. At
minimum, any IPng control protocol should return the entire IPng
and transport headers (including options or nested headers).
Time Frame
Support for these functions is required immediately.
5.17 Private Networks
CRITERION
IPng must allow users to build private internetworks on top of the
basic Internet Infrastructure. Both private IP-based
internetworks and private non-IP-based (e.g., CLNP or AppleTalk)
internetworks must be supported.
DISCUSSION
In the current Internet, these capabilities are used by the
research community to develop new IP services and capabilities
(e.g., the MBone) and by users to interconnect non-IP islands over
the Internet (e.g., CLNP and DecNet use in the UK).
The capability of building networks on top of the Internet have
been shown to be useful. Private networks allow the Internet to
Partridge and Kastenholz [Page 25]
RFC 1726 IPng Technical Criteria December 1994
be extended and modified in ways that 1) were not foreseen by the
original builders and 2) do not disrupt the day-to-day operations
of other users.
We note that, today in the IPv4 Internet, tunneling is widely used
to provide these capabilities.
Finally, we note that there might not be any features that
specifically need to be added to IPng in order to support the
desired functions (i.e., one might treat a private network protocol
simply as another IP client protocol, just like TCP or UDP). If
this is the case, then IPng must not prevent these functions from
being performed.
Time Frame
Some of these capabilities may be required to support other
criteria (e.g., transition) and as such, the timing of the
specifications is governed by the other criteria (e.g., immediately
in the case of transition). Others may be produced as desired.
6. Things We Chose Not to Require
This section contains items which we felt should not impact the
choice of an IPng. Listing an item here does not mean that a
protocol MUST NOT do something. It means that the authors do not
believe that it matters whether the feature is in the protocol or
not. If a protocol includes one of the items listed here, that's
cool. If it doesn't; that's cool too. A feature might be necessary in
order to meet some other criterion. Our point is merely that the
feature need not be required for its own sake.
6.1 Fragmentation
The technology exists for path MTU discovery. Presumably, IPng will
continue to provide this technology. Therefore, we believe that IPng
Fragmentation and Reassembly, as provided in IPv4, is not necessary.
We note that fragmentation has been shown to be detrimental to
network performance and strongly recommend that it be avoided.
6.2 IP Header Checksum
There has been discussion indicating that the IP Checksum does not
provide enough error protection to warrant its performance impact.
The argument states that there is almost always a stronger datalink
level CRC, and that end-to-end protection is provided by the TCP
checksum. Therefore we believe that an IPng checksum is not required
per-se.
Partridge and Kastenholz [Page 26]
RFC 1726 IPng Technical Criteria December 1994
6.3 Firewalls
Some have requested that IPng include support for firewalls. The
authors believe that firewalls are one particular solution to the
problem of security and, as such, do not consider that support for
firewalls is a valid requirement for IPng. (At the same time, we
would hope that no IPng is hostile to firewalls without offering some
equivalent security solution).
6.4 Network Management
Network Management properly is a task to be carried out by additional
protocols and standards, such as SNMP and its MIBs. We believe that
network management, per se, is not an attribute of the IPng protocol.
Furthermore, network management is viewed as a support, or service,
function. Network management should be developed to fit IPng and not
the other way round.
6.5 Accounting
We believe that accounting, like network management, must be designed
to fit the IPng protocol, and not the other way round. Therefore,
accounting, in and of itself, is not a requirement of IPng. However,
there are some facets of the protocol that have been specified to
make accounting easier, such as non-repudiation of origin under
security, and the unique naming requirement for sorting datagrams
into classes. Note that a parameter of network service that IPng
must support is cost.
6.6 Routing
Routing is a very critical part of the Internet. In fact, the
Internet Engineering Task Force has a separate Area which is
chartered to deal only with routing issues. This Area is separate
from the more general Internet Area.
We see that routing is also a critical component of IPng. There are
several criteria, such as Scaling, Addressing, and Network Services,
which are intimately entwined with routing. In order to stress the
critical nature and importance of routing, we have chosen to devote a
separate chapter to specifically enumerating some of the requirements
and issues that IPng routing must address. All of these issues, we
believe, fall out of the general criteria presented in the previous
chapter.
Partridge and Kastenholz [Page 27]
RFC 1726 IPng Technical Criteria December 1994
6.6.1 Scale
First and foremost, the routing architecture must scale to support
a very large Internet. Current expectations are for an Internet
of about 10**9 to 10**12 networks. The routing architecture must
be able to deal with networks of this size. Furthermore, the
routing architecture must be able to deal with this size without
requiring massive, global databases and algorithms. Such
databases or algorithms would, in effect, be single points of
failure in the architecture (which is not robust), and because of
the nature of Internet administration (cooperative anarchy), it
would be impossible to maintain the needed consistency.
6.6.2 Policy
Networks (both transit and non-transit) must be able to set their
own policies for the types of traffic that they will admit. The
routing architecture must make these policies available to the
network as a whole. Furthermore, nodes must be able to select
routes for their traffic based on the advertised policies.
6.6.3 QOS
A key element of the network service criteria is that differing
applications wish to acquire differing grades of network service.
It is essential that this service information be propagated around
the network.
6.6.4 Feedback
As users select specific routes over which to send their traffic,
they must be provided feedback from the routing architecture. This
feedback should allow the user to determine whether the desired
routes are actually available or not, whether the desired services
are being provided, and so forth.
This would allow users to modify their service requirements or
even change their routes, as needed.
6.6.5 Stability
With the addition of additional data into the routing system
(i.e., routes are based not only on connectivity, as in IPv4, but
also on policies, service grades, and so on), the stability of the
routes may suffer. We offer as evidence the early ARPANET which
experimented with load-based routing. Routes would remain in flux,
changing from one saturated link, to another, unused, link.
Partridge and Kastenholz [Page 28]
RFC 1726 IPng Technical Criteria December 1994
This must not be allowed to happen. If anything, routes should be
even more stable under IPng's routing architecture than under the
current architecture.
6.6.6 Multicast
Multicast will be more important in IPng than it is today in IPv4.
Multicast groups may be very large and very distributed.
Membership in multicast groups will be very dynamic. The routing
architecture must be able to cope with this.
Furthermore, the routing architecture must be able to build
multicast routes dynamically, based on factors such as group
membership, member location, requested and available qualities of
service, and so on.
7. References
[1] Internet Architecture Board, "IP Version 7", Draft 8, Work in
Progress, July, 1992.
[2] Gross, P., and P. Almquist, "IESG Deliberations on Routing and
Addressing", RFC 1380, IESG Chair, IESG Internet AD, November
1992.
[3] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Toward the Future Internet Architecture", RFC 1287, MIT, BBN,
CNRI, USC/Information Sciences Institute, UC Davis, December
1991.
[4] Dave Clark's paper at SIGCOMM '88 where he pointed out that the
design of TCP/IP was guided, in large part, by an ordered list of
requirements.
[5] Vecchi, M., "IPng Requirements: A Cable Television Industry
Viewpoint", RFC 1686, Time Warner Cable, August 1994.
[6] Green, D., Irey, P., Marlow, D. and K. O'Donoghue, "HPN Working
Group Input to the IPng Requirements Solicitation, RFC 1679,
NSWC-DD, August 1994.
[7] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T Bell
Laboratories, August 1994.
[8] Symington, S., Wood, D., and J. Pullen, "Modelling and Simulation
Requirements for IPng", RFC 1667, Mitre Corporation and George
Mason University, August 1994.
Partridge and Kastenholz [Page 29]
RFC 1726 IPng Technical Criteria December 1994
[9] Internet Architecture Board, "Report of the IAB Workshop on
Security in the Internet Architecture, RFC 1636, IAB, June 1994.
[10] Private EMAIL from Tony Li to IPNG Directorate Mailing List, 18
April 1994 18:42:05.
[11] Saltzer, J., On the Naming and Binding of Network Destinations",
RFC 1498, M.I.T. Laboratory for Computer Science, August 1993.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", STD 7, RFC 793, DARPA, September
1981.
[13] EMAIL from Robert Elz to the Big Internet mailing list,
approximately 4 May 1994.
[14] Chiappa, N., "Nimrod and IPng Technical Requirements", Work in
Progress.
8. Security Considerations
Security is not directly addressed by this memo. However, as this
memo codifies goals for a new generation of network layer protocol,
the security provided by such a protocol is addressed. Security has
been raised as an issue in several of the requirements stated in this
memo. Furthermore, a specific requirement for security has been
made.
9. Acknowledgements
The authors gratefully acknowledge the assistance and input provided
by the many people who have reviewed and commented upon this
document.
Partridge and Kastenholz [Page 30]
RFC 1726 IPng Technical Criteria December 1994
10. Authors' Addresses
Craig Partridge
BBN Systems and Technologies
10 Moulton St.
Cambridge, MA 02138
EMail: craig@aland.bbn.com
Frank Kastenholz
FTP Software, Inc.
2 High St.
North Andover, MA, 01845-2620 USA
EMail: kasten@ftp.com
Partridge and Kastenholz [Page 31]
|