File: rfc1752.txt

package info (click to toggle)
doc-rfc 1999.08-1
  • links: PTS
  • area: main
  • in suites: potato
  • size: 68,428 kB
  • ctags: 6
  • sloc: sh: 2,491; perl: 390; makefile: 44
file content (2915 lines) | stat: -rw-r--r-- 127,784 bytes parent folder | download | duplicates (9)
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
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915






Network Working Group                                         S. Bradner
Request for Comments: 1752                            Harvard University
Category: Standards Track                                      A. Mankin
                                                                     ISI
                                                            January 1995


         The Recommendation for the IP Next Generation Protocol

Status of this Memo

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

Abstract

   This document presents the recommendation of the IPng Area Directors
   on what should be used to replace the current version of the Internet
   Protocol.  This recommendation was accepted by the Internet
   Engineering Steering Group (IESG).

Table of Contents

   1.        Summary. . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.        Background . . . . . . . . . . . . . . . . . . . . . . .  4
   3.        A Direction for IPng . . . . . . . . . . . . . . . . . .  5
   4.        IPng Area. . . . . . . . . . . . . . . . . . . . . . . .  6
   5.        ALE Working Group. . . . . . . . . . . . . . . . . . . .  6
     5.1     ALE Projections. . . . . . . . . . . . . . . . . . . . .  7
     5.2     Routing Table Size . . . . . . . . . . . . . . . . . . .  7
     5.3     Address Assignment Policy Recommendations. . . . . . . .  8
   6.        IPng Technical Requirements. . . . . . . . . . . . . . .  8
     6.1     The IPng Technical Criteria document . . . . . . . . . .  9
   7.        IPng Proposals . . . . . . . . . . . . . . . . . . . . . 11
     7.1     CATNIP. . .  . . . . . . . . . . . . . . . . . . . . . . 11
     7.2     SIPP. . . .  . . . . . . . . . . . . . . . . . . . . . . 12
     7.3     TUBA. . . .  . . . . . . . . . . . . . . . . . . . . . . 13
   8.        IPng Proposal Reviews. . . . . . . . . . . . . . . . . . 13
     8.1     CATNIP Reviews . . . . . . . . . . . . . . . . . . . . . 14
     8.2     SIPP Reviews . . . . . . . . . . . . . . . . . . . . . . 15
     8.3     TUBA Reviews . . . . . . . . . . . . . . . . . . . . . . 16
     8.4     Summary of Proposal Reviews. . . . . . . . . . . . . . . 17
   9.        A Revised Proposal . . . . . . . . . . . . . . . . . . . 17
   10        Assumptions .  . . . . . . . . . . . . . . . . . . . . . 18
     10.1    Criteria Document and Timing of Recommendation . . . . . 18



Bradner & Mankin                                                [Page 1]

RFC 1752                Recommendation for IPng             January 1995


     10.2    Address Length . . . . . . . . . . . . . . . . . . . . . 19
   11.       IPng Recommendation. . . . . . . . . . . . . . . . . . . 19
     11.1    IPng Criteria Document and IPng. . . . . . . . . . . . . 20
     11.2    IPv6. . . . .  . . . . . . . . . . . . . . . . . . . . . 21
   12.       IPv6 Overview  . . . . . . . . . . . . . . . . . . . . . 21
     12.1    IPv6 Header Format . . . . . . . . . . . . . . . . . . . 24
     12.2    Extension Headers. . . . . . . . . . . . . . . . . . . . 25
     12.2.1  Hop-by-Hop Option Header . . . . . . . . . . . . . . . . 25
     12.2.2  IPv6 Header Options. . . . . . . . . . . . . . . . . . . 26
     12.2.3  Routing Header . . . . . . . . . . . . . . . . . . . . . 27
     12.2.4  Fragment Header. . . . . . . . . . . . . . . . . . . . . 28
     12.2.5  Authentication Header. . . . . . . . . . . . . . . . . . 29
     12.2.6  Privacy Header . . . . . . . . . . . . . . . . . . . . . 30
     12.2.7  End-to-End Option Header . . . . . . . . . . . . . . . . 32
   13.       IPng Working Group . . . . . . . . . . . . . . . . . . . 32
   14.       IPng Reviewer  . . . . . . . . . . . . . . . . . . . . . 33
   15.       Address Autoconfiguration. . . . . . . . . . . . . . . . 33
   16.       Transition . . . . . . . . . . . . . . . . . . . . . . . 34
     16.1    Transition - Short Term. . . . . . . . . . . . . . . . . 35
     16.2    Transition - Long Term . . . . . . . . . . . . . . . . . 36
   17.       Other Address Families . . . . . . . . . . . . . . . . . 37
   18.       Impact on Other IETF Standards . . . . . . . . . . . . . 38
   19.       Impact on non-IETF standards and on products . . . . . . 39
   20.       APIs . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   21.       Future of the IPng Area and Working Groups . . . . . . . 40
   22.       Security Considerations. . . . . . . . . . . . . . . . . 40
   23.       Authors' Addresses . . . . . . . . . . . . . . . . . . . 43

   Appendix A    Summary of Recommendations . . . . . . . . . . . . . 44
   Appendix B    IPng Area Directorate. . . . . . . . . . . . . . . . 45
   Appendix C    Documents Referred to the IPng Working Groups. . . . 46
   Appendix D    IPng Proposal Overviews. . . . . . . . . . . . . . . 46
   Appendix E    RFC 1550 White Papers. . . . . . . . . . . . . . . . 47
   Appendix F    Additional References. . . . . . . . . . . . . . . . 48
   Appendix G    Acknowledgments. . . . . . . . . . . . . . . . . . . 52

1. Summary

   The IETF started its effort to select a successor to IPv4 in late
   1990 when projections indicated that the Internet address space would
   become an increasingly limiting resource.  Several parallel efforts
   then started exploring ways to resolve these address limitations
   while at the same time providing additional functionality.  The IETF
   formed the IPng Area in late 1993 to investigate the various
   proposals and recommend how to proceed.  We developed an IPng
   technical criteria document and evaluated the various proposals
   against it.  All were found wanting to some degree.  After this
   evaluation, a revised proposal was offered by one of the working



Bradner & Mankin                                                [Page 2]

RFC 1752                Recommendation for IPng             January 1995


   groups that resolved many of the problems in the previous proposals.
   The IPng Area Directors recommend that the IETF designate this
   revised proposal as the IPng and focus its energy on bringing a set
   of documents defining the IPng to Proposed Standard status with all
   deliberate speed.

   This protocol recommendation includes a simplified header with a
   hierarchical address structure that permits rigorous route
   aggregation and is also large enough to meet the needs of the
   Internet for the foreseeable future. The protocol also includes
   packet-level authentication and encryption along with plug and play
   autoconfiguration.  The design changes the way IP header options are
   encoded to increase the flexibility of introducing new options in the
   future while improving performance. It also includes the ability to
   label traffic flows.

   Specific recommendations include:

   * current address assignment policies are adequate
   * there is no current need to reclaim underutilized assigned network
     numbers
   * there is no current need to renumber major portions of the Internet
   * CIDR-style assignments of parts of unassigned Class A address space
     should be considered
   * "Simple Internet Protocol Plus (SIPP) Spec. (128 bit ver)"
     [Deering94b] be adopted as the basis for IPng
   * the documents listed in Appendix C be the foundation of the IPng
     effort
   * an IPng Working Group be formed, chaired by Steve Deering and Ross
     Callon
   * Robert Hinden be the document editor for the IPng effort
   * an IPng Reviewer be appointed and that Dave Clark be the reviewer
   * an Address Autoconfiguration Working Group be formed, chaired by
     Dave Katz and Sue Thomson
   * an IPng Transition Working Group be formed, chaired by Bob Gilligan
     and TBA
   * the Transition and Coexistence Including Testing Working Group be
     chartered
   * recommendations about the use of non-IPv6 addresses in IPv6
     environments and IPv6 addresses in non-IPv6 environments be
     developed
   * the IESG commission a review of all IETF standards documents for
     IPng implications
   * the IESG task current IETF working groups to take IPng into account
   * the IESG charter new working groups where needed to revise old
     standards documents
   * Informational RFCs be solicited or developed describing a few
     specific IPng APIs



Bradner & Mankin                                                [Page 3]

RFC 1752                Recommendation for IPng             January 1995


   * the IPng Area and Area Directorate continue until main documents
     are offered as Proposed Standards in late 1994
   * support for the Authentication Header be required
   * support for a specific authentication algorithm be required
   * support for the Privacy Header be required
   * support for a specific privacy algorithm be required
   * an "IPng framework for firewalls" be developed

2. Background

   Even the most farseeing of the developers of TCP/IP in the early
   1980s did not imagine the dilemma of scale that the Internet faces
   today.  1987 estimates projected a need to address as many as 100,000
   networks at some vague point in the future. [Callon87]  We will reach
   that mark by 1996.  There are many realistic projections of many
   millions of interconnected networks in the not too distant future.
   [Vecchi94, Taylor94]

   Further, even though the current 32 bit IPv4 address structure can
   enumerate over 4 billion hosts on as many as 16.7 million networks,
   the actual address assignment efficiency is far less than that, even
   on a theoretical basis. [Huitema94]  This inefficiency is exacerbated
   by the granularity of assignments using Class A, B and C addresses.

   In August 1990 during the Vancouver IETF meeting, Frank Solensky,
   Phill Gross and Sue Hares projected that the current rate of
   assignment would exhaust the Class B space by March of 1994.

   The then obvious remedy of assigning multiple Class C addresses in
   place of Class B addresses introduced its own problem by further
   expanding the size of the routing tables in the backbone routers
   already growing at an alarming rate.

   We faced the dilemma of choosing between accepting either limiting
   the rate of growth and ultimate size of the Internet, or disrupting
   the network by changing to new techniques or technologies.

   The IETF formed the Routing and Addressing (ROAD) group in November
   1991 at the Santa Fe IETF meeting to explore this dilemma and guide
   the IETF on the issues.  The ROAD group reported their work in March
   1992 at the San Diego IETF meeting.  [Gross92]  The impact of the
   recommendations ranged from "immediate" to "long term" and included
   adopting the CIDR route aggregation proposal [Fuller93] for reducing
   the rate of routing table growth and recommending a call for
   proposals "to form working groups to explore separate approaches for
   bigger Internet addresses."





Bradner & Mankin                                                [Page 4]

RFC 1752                Recommendation for IPng             January 1995


   In the late spring of 1992 the IAB issued "IP version 7" [IAB92],
   concurring in the ROAD group's endorsement of CIDR and also
   recommending "an immediate IETF effort to prepare a detailed and
   organizational plan for using CLNP as the basis for IPv7." After
   spirited discussion, the IETF decided to reject the IAB's
   recommendation and issue the call for  proposals recommended by the
   ROAD group.  This call was issued in July 1992 at the Boston IETF
   meeting and a number of working groups were formed in response

   During the July 1993 Amsterdam IETF meeting an IPng (IP Next
   Generation) Decision Process (ipdecide) BOF was held.  This BOF "was
   intended to help re-focus attention on the very important topic of
   making a decision between the candidates for IPng. The BOF focused on
   the issues of who should take the lead in making the recommendation
   to the community and what criteria should be used to reach the
   recommendation." [Carpen93]

3. A Direction for IPng

   In September 1993 Phill Gross, chair of the IESG issued "A Direction
   for IPng".  [Gross94]  In this memo he summarized the results of the
   ipdecide BOF and open IESG plenary in Amsterdam.

   * The IETF needs to move toward closure on IPng.
   * The IESG has the responsibility for developing an IPng
     recommendation for the Internet community.
   * The procedures of the recommendation-making process should be open
     and published well in advance by the IESG.
   * As part of this process, the IPng WGs may be given new milestones
     and other guidance to aid the IESG.
   * There should be ample opportunity for community comment prior to
     final IESG recommendation.

   The memo also announced "a temporary, ad hoc, 'area' to deal
   specifically with IPng issues."  Phill asked two of the current IESG
   members, Allison Mankin (Transport Services Area) and Scott Bradner
   (Operational Requirements Area), to act as Directors for the new
   area. The Area Directors were given a specific charge on how to
   investigate the various IPng proposals and how to base their
   recommendation to the IETF.  It was also requested that a specific
   recommendation be made.

   * Establish an IPng directorate.
   * Ensure that a completely open process is followed.
   * Develop an understanding of the level of urgency and the time
     constraints imposed by the rate of address assignment and rate of
     growth in the routing tables.
   * Recommend the adoption of assignment policy changes if warranted.



Bradner & Mankin                                                [Page 5]

RFC 1752                Recommendation for IPng             January 1995


   * Define the scope of the IPng effort based on the understanding of
     the time constraints.
   * Develop a clear and concise set of technical requirements and
     decision criteria for IPng.
   * Develop a recommendation about which of the current IPng candidates
     to accept, if any.

4. IPng Area

   After the IPng Area was formed, we recruited a directorate. (Appendix
   B) The members of the directorate were chosen both for their general
   and specific technical expertise.  The individuals were then asked to
   have their management authorize this participation in the process and
   confirm that they understood the IETF process.

   We took great care to ensure the inclusion of a wide spectrum of
   knowledge. The directors are experts in security, routing, the needs
   of large users, end system manufacturers, Unix and non-Unix
   platforms, router manufacturers, theoretical researchers, protocol
   architecture, and the operating regional, national, and international
   networks.  Additionally, several members of the directorate were
   deeply involved in each of the IPng proposal working groups.

   The directorate functions as a direction-setting and preliminary
   review body as requested by the charge to the area.  The directorate
   engages in biweekly conference calls, participates in an internal
   mailing list and corresponds actively on the Big-Internet mailing
   list. The directorate held open meetings during the March 1994
   Seattle and July 1994 Toronto IETF meetings as well as two additional
   multi-day retreats.  To ensure that the IPng process was as open as
   possible, we took minutes during these meetings and then published
   them. Additionally, we placed the archives of the internal IPng
   mailing list on an anonymous ftp site. (Hsdndev.harvard.edu:
   pub/ipng.)

5. ALE Working Group

   We needed a reasonable estimate of the time remaining before we
   exhausted the IPv4 address space in order to determine the scope of
   the IPng effort.  If the time remaining was about the same needed to
   deploy a replacement, then we would have select the IPng which would
   only fix the address limitations since we would not have enough time
   to develop any other features.  If more time seemed available, we
   could consider additional improvements.

   The IETF formed an Address Lifetime Expectations (ALE) Working Group
   in 1993 "to develop an estimate for the remaining lifetime of the
   IPv4 address space based on currently known and available



Bradner & Mankin                                                [Page 6]

RFC 1752                Recommendation for IPng             January 1995


   technologies." [Solens93a]  Tony Li of Cisco Systems and Frank
   Solensky of FTP Software are the co-chairs.  The IETF also charged
   the working group to consider if developing more stringent address
   allocation and utilization policies might provide more time for the
   transition.

5.1 ALE Projections

   The ALE Working Group met during the November 1993 Houston,
   [Solens93b] March 1994 Seattle [Bos93] and July 1994 Toronto
   [Solens94] IETF meetings.  They projected at the Seattle meeting,
   later confirmed at the Toronto meeting that, using the current
   allocation statistics, the Internet would exhaust the IPv4 address
   space between 2005 and 2011.

   Some members of the ipv4-ale and big-internet mailing lists called
   into question the reliability of this projection.  It has been
   criticized as both too optimistic and as too pessimistic.

   Some people pointed out that this type of projection makes an
   assumption of no paradigm shifts in IP usage.  If someone were to
   develop a new 'killer application', (for example cable-TV set top
   boxes.)  The resultant rise in the demand for IP addresses could make
   this an over-estimate of the time available.

   There may also be a problem with the data used to make the
   projection.  The InterNIC allocates IP addresses in large chunks to
   regional Network Information Centers (NICs) and network providers.
   The NICs and the providers then re-allocate addresses to their
   customers.  The ALE projections used the InterNIC assignments without
   regard to the actual rate of assignment of addresses to the end
   users.  They did the projection this way since the accuracy of the
   data seems quite a bit higher.  While using this once-removed data
   may add a level of over-estimation since it assumes the rate of large
   block allocation will continue, this may not be the case.

   These factors reduce the reliability of the ALE estimates but, in
   general, they seem to indicate enough time remaining in the IPv4
   address space to consider adding features in an IPng besides just
   expanding the address size even when considering time required for
   development, testing, and deployment.

5.2 Routing Table Size

   Another issue in Internet scaling is the increasing size of the
   routing tables required in the backbone routers.  Adopting the CIDR
   block address assignment and aggregating routes reduced the size of
   the tables for awhile but they are now expanding again. Providers now



Bradner & Mankin                                                [Page 7]

RFC 1752                Recommendation for IPng             January 1995


   need to more aggressively advertise their routes only in aggregates.
   Providers must also advise their new customers to renumber their
   networks in the best interest of the entire Internet community.

   The problem of exhausting the IPv4 address space may be moot if this
   issue is ignored and if routers cannot be found that can keep up with
   the table size growth.  Before implementing CIDR the backbone routing
   table was growing at a rate about 1.5 times as fast as memory
   technology.

   We should also note that even though IPng addresses are designed with
   aggregation in mind switching to IPng will not solve the routing
   table size problem unless the addresses are assigned rigorously to
   maximize the affect of such aggregation.  This efficient advertising
   of routes can be maintained since IPng includes address
   autoconfiguration mechanisms to allow easy renumbering if a customer
   decides to switch providers.  Customers who receive service from more
   than one provider may limit the ultimate efficiency of any route
   aggregation. [Rekhter94]

5.3 Address Assignment Policy Recommendations

   The IESG Chair charged the IPng Area to consider recommending more
   stringent assignment policies, reclaiming some addresses already
   assigned, or making a serious effort to renumber significant portions
   of the Internet. [Gross94]

   The IPng Area Directors endorse the current address assignment
   policies in view of the ALE projections.  We do not feel that anyone
   should take specific efforts to reclaim underutilized addresses
   already assigned or to renumber forcefully major portions of the
   Internet.  We do however feel that we should all encourage network
   service providers to assist new customers in renumbering their
   networks to conform to the provider's CIDR assignments.

   The ALE Working Group recommends that we consider assigning CIDR-type
   address blocks out of the unassigned Class A address space.  The IPng
   Area Directors concur with this recommendation.

6. IPng Technical Requirements

   The IESG provided an outline in RFC 1380 [Gross92] of the type of
   criteria we should use to determine the suitability of an IPng
   proposal.  The IETF further refined this understanding of the
   appropriate criteria with the recommendations of a Selection Criteria
   BOF held during the November 1992 IETF meeting in Washington D.C.
   [Almqu92]  We felt we needed to get additional input for determining
   the requirements and issued a call for white papers. [Bradner93] This



Bradner & Mankin                                                [Page 8]

RFC 1752                Recommendation for IPng             January 1995


   call, issued as RFC 1550, intended to reach both inside and outside
   the traditional IETF constituency to get the broadest possible
   understanding of the requirements for a data networking protocol with
   the broadest possible application.

   We received twenty one white papers in response to the RFC 1550
   solicitation. ( Appendix E)  We received responses from the
   industries that many feel will be the major providers of data
   networking services in the future; the cable TV industry [Vecchi94],
   the cellular industry [Taylor94], and the electric power industry
   [Skelton94].  In addition, we received papers that dealt with
   military applications [Adam94, Syming94, Green94], ATM [Brazd94],
   mobility [Simpson94], accounting [Brown94], routing [Estrin94a,
   Chiappa94], security [Adam94, Bell94b, Brit94, Green94, Vecchi94,
   Flei94], large corporate networking [Britt94, Fleisch94], transition
   [Carpen94a, Heager94], market acceptance [Curran94, Britt94], host
   implementations [Bound94], as well as a number of other issues.
   [Bello94a, Clark94, Ghisel94]

   These white papers, a Next Generation Requirements (ngreq) BOF
   (chaired by Jon Crowcroft and Frank Kastenholz) held during the March
   1994 Seattle IETF meeting, discussions within the IPng Area
   Directorate and considerable discussion on the big-internet mailing
   list were all used by Frank Kastenholz and Craig Partridge in
   revising their earlier criteria draft [Kasten92] to produce
   "Technical Criteria for Choosing IP The Next Generation (IPng)."
   [Kasten94]  This document is the "clear and concise set of technical
   requirements and decision criteria for IPng" called for in the charge
   from the IESG Chair.  We used this document as the basic guideline
   while evaluating the IPng proposals.

6.1 The IPng Technical Criteria document

   The criteria described in this document include: (from Kasten94)

   * complete specification - The proposal must completely describe the
     proposed protocol.  We must select an IPng by referencing specific
     documents, not to future work.
   * architectural simplicity - The IP-layer protocol should be as
     simple as possible with functions located elsewhere that are more
     appropriately performed at protocol layers other than the IP layer.
   * scale - The IPng Protocol must allow identifying and addressing at
     least 10**9 leaf-networks (and preferably much more)
   * topological flexibility - The routing architecture and protocols
     ofIPng must allow for many different network topologies.  They must
     not assume that the network's physical structure is a tree.
   * performance - A state of the art, commercial grade router must be
     able to process and forward IPng traffic at speeds capable of fully



Bradner & Mankin                                                [Page 9]

RFC 1752                Recommendation for IPng             January 1995


     utilizing common, commercially available, high-speed media at the
     time.
   * robust service - The network service and its associated routing and
     control protocols must be robust.
   * transition -  The protocol must have a straightforward transition
     plan from IPv4.
   * media independence -  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.
   * datagram service - The protocol must support an unreliable datagram
     delivery service.
   * configuration ease -  The protocol must permit easy and largely
     distributed configuration and operation. Automatic configuration of
     hosts and routers is required.
   * security - IPng must provide a secure network layer.
   * unique names - IPng must assign unique names to all IP-Layer
     objects in the global, ubiquitous, Internet.  These names may or
     may not have any location, topology, or routing significance.
   * access to standards -  The protocols that define IPng and its
     associated protocols 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.
   * multicast support - The protocol must support both unicast and
     multicast packet transmission.   Dynamic and automatic routing of
     multicasts is also required.
   * extensibility -  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.
   * service classes - The protocol must allow network devices to
     associate packets with particular service classes and provide them
     with the  services specified by those classes.
   * mobility - The protocol must support mobile hosts, networks and
     internetworks.
   * control protocol - The protocol must include elementary support for
     testing and debugging networks. (e.g., ping and traceroute)
   * tunneling support -  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.









Bradner & Mankin                                               [Page 10]

RFC 1752                Recommendation for IPng             January 1995


7. IPng Proposals

   By the time that the IPng Area was formed, the IETF had already aimed
   a considerable amount of IETF effort at solving the addressing and
   routing problems of the Internet.  Several proposals had been made
   and some of these reached the level of having a working group
   chartered.  A number of these groups subsequently merged forming
   groups with a larger consensus.  These efforts represented different
   views on the issues which confront us and sought to optimize
   different aspects of the possible solutions.

   By February 1992 the Internet community developed four separate
   proposals for IPng [Gross92], "CNAT" [Callon92a], "IP Encaps"
   [Hinden92a], "Nimrod" [Chiappa91], and "Simple CLNP" [Callon92b].  By
   December 1992 three more proposals followed; "The P Internet
   Protocol" (PIP) [Tsuchiya92], "The Simple Internet Protocol" (SIP)
   [Deering92] and "TP/IX" [Ullmann93]. After the March 1992 San Diego
   IETF meeting "Simple CLNP" evolved into "TCP and UDP with Bigger
   Addresses" (TUBA) [Callon92c] and "IP Encaps" evolved into "IP
   Address Encapsulation" (IPAE) [Hinden92b].

   By November 1993, IPAE merged with SIP while still maintaining the
   name SIP. This group then merged with PIP and the resulting working
   group called themselves "Simple Internet Protocol Plus" (SIPP).  At
   the same time the TP/IX Working Group changed its name to "Common
   Architecture for the Internet" (CATNIP).

   None of these proposals were wrong nor were others right.  All of the
   proposals would work in some ways providing a path to overcome the
   obstacles we face as the Internet expands. The task of the IPng Area
   was to ensure that the IETF understand the offered proposals, learn
   from the proposals and provide a recommendation on what path best
   resolves the basic issues while providing the best foundation upon
   which to build for the future.

   The IPng Area evaluated three IPng proposals as they were described
   in their RFC 1550 white papers: CATNIP [McGovern94] , SIPP
   [Hinden94a] and TUBA. [Ford94a]. The IESG viewed Nimrod as too much
   of a research project for consideration as an IPng candidate.  Since
   Nimrod represents one possible future Internet routing strategy we
   solicited a paper describing any requirements Nimrod would put on an
   IPng to add to the requirements process. [Chiappa94]

7.1 CATNIP

   "Common Architecture for the Internet (CATNIP) was conceived as a
   convergence protocol. CATNIP integrates CLNP, IP, and IPX. The CATNIP
   design provides for any of the transport layer protocols in use, for



Bradner & Mankin                                               [Page 11]

RFC 1752                Recommendation for IPng             January 1995


   example TP4, CLTP, TCP, UDP, IPX and SPX, to run over any of the
   network layer protocol formats: CLNP, IP (version 4), IPX, and
   CATNIP.  With some attention paid to details, it is possible for a
   transport layer protocol (such as TCP) to operate properly with one
   end system using one network layer (e.g., IP version 4) and the other
   using some other network protocol, such as CLNP." [McGovern94]

   "The objective is to provide common ground between the Internet, OSI,
   and the Novell protocols, as well as to advance the Internet
   technology to the scale and performance of the next generation of
   internetwork technology."

   "CATNIP supports OSI Network Service Access Point (NSAP) format
   addresses.  It also uses cache handles to provide both rapid
   identification of the next hop in high performance routing as well as
   abbreviation of the network header by permitting the addresses to be
   omitted when a valid cache handle is available. The fixed part of the
   network layer header carries the cache handles." [Sukonnik94]

7.2 SIPP

   "Simple Internet Protocol Plus (SIPP) is a new version of IP which is
   designed to be an evolutionary step from IPv4.  It is a natural
   increment to IPv4.  It was not a design goal to take a radical step
   away from IPv4.  Functions which work in IPv4 were kept in SIPP.
   Functions which didn't work were removed. It can be installed as a
   normal software upgrade in internet devices and is interoperable with
   the current IPv4.  Its deployment strategy was designed to not have
   any 'flag' days.  SIPP is designed to run well on high performance
   networks (e.g., ATM) and at the same time is still efficient for low
   bandwidth networks (e.g., wireless).  In addition, it provides a
   platform for new internet functionality that will be required in the
   near future." [Hinden94b]

   "SIPP increases the IP address size from 32 bits to 64 bits, to
   support more levels of addressing hierarchy and a much greater number
   of addressable nodes.  SIPP addressing can be further extended, in
   units of 64 bits, by a facility equivalent to IPv4's Loose Source and
   Record Route option, in combination with a new address type called
   'cluster addresses' which identify topological regions rather than
   individual nodes."

   "SIPP changes in the way IP header options are encoded allows for
   more efficient forwarding, less stringent limits on the length of
   options, and greater flexibility for introducing new options in the
   future. A new capability is added to enable the labeling of packets
   belonging to particular traffic 'flows' for which the sender requests
   special handling, such as non-default quality of service or 'real-



Bradner & Mankin                                               [Page 12]

RFC 1752                Recommendation for IPng             January 1995


   time' service." [Hinden94a]

7.3 TUBA

   "The TCP/UDP Over CLNP-Addressed Networks (TUBA) proposal seeks to
   minimize the risk associated with migration to a new IP address
   space. In addition, this proposal is motivated by the requirement to
   allow the Internet to scale, which implies use of Internet
   applications in a very large ubiquitous worldwide Internet. It is
   therefore proposed that existing Internet transport and application
   protocols continue to operate unchanged, except for the replacement
   of 32-bit IP addresses with larger addresses.  TUBA does not mean
   having to move over to OSI completely. It would mean only replacing
   IP with CLNP. TCP, UDP, and the traditional TCP/IP applications would
   run on top of CLNP." [Callon92c]

   "The TUBA effort will expand the ability to route Internet packets by
   using addresses which support more hierarchy than the current
   Internet Protocol (IP) address space. TUBA specifies the continued
   use of Internet transport protocols, in particular TCP and UDP, but
   specifies their encapsulation in ISO 8473 (CLNP) packets.  This will
   allow the continued use of Internet application protocols such as
   FTP, SMTP, TELNET, etc.   TUBA seeks to upgrade the current system by
   a transition from the use of IPv4 to ISO/IEC 8473 (CLNP) and the
   corresponding large Network Service Access Point (NSAP) address
   space." [Knopper94]

   "The TUBA proposal makes use of a simple long-term migration proposal
   based on a gradual update of Internet Hosts (to run Internet
   applications over CLNP) and DNS servers (to return larger addresses).
   This proposal requires routers to be updated to support forwarding of
   CLNP (in addition to IP). However, this proposal does not require
   encapsulation nor translation of packets nor address mapping. IP
   addresses and NSAP addresses may be assigned and used independently
   during the migration period. Routing and forwarding of IP and CLNP
   packets may be done independently." ([Callon92c]

8. IPng Proposal Reviews

   The IPng Directorate discussed and reviewed the candidate proposals
   during its biweekly teleconferences and through its mailing list.  In
   addition, members of the Big-Internet mailing list discussed many of
   the aspects of the proposals, particularly when the Area Directors
   posted several specific questions to stimulate discussion. [Big]

   The directorate members were requested to each evaluate the proposals
   in preparation for a two day retreat held near Chicago on May 19th
   and 20th 1994.  The retreat opened with a roundtable airing of the



Bradner & Mankin                                               [Page 13]

RFC 1752                Recommendation for IPng             January 1995


   views of each of the participants, including the Area Directors, the
   Directorate and a number of guests invited by the working group
   chairs for each for the proposals. [Knopper94b]  We will publish
   these reviews as well as a more detailed compendium review of each of
   the proposals as companion memos.

   The following table summarizes each of the three proposals reviewed
   against the requirements in the IPng Criteria document.  They do not
   necessarily reflect the views of the Area Directors.  "Yes" means the
   reviewers mainly felt the proposal met the specific criterion.  "No"
   means the reviewers mainly felt the proposal did not meet the
   criterion.  "Mixed" means that the reviewers had mixed reviews with
   none dominating. "Unknown" means that the reviewers mainly felt the
   documentation did not address the criterion.

                           CATNIP          SIPP            TUBA
                           ------          ----            ----
   complete spec           no              yes             mostly
   simplicity              no              no              no
   scale                   yes             yes             yes
   topological flex        yes             yes             yes
   performance             mixed           mixed           mixed
   robust service          mixed           mixed           yes
   transition              mixed           no              mixed
   media indepdnt          yes             yes             yes
   datagram                yes             yes             yes
   config. ease            unknown         mixed           mixed
   security                unknown         mixed           mixed
   unique names            mixed           mixed           mixed
   access to stds          yes             yes             mixed
   multicast               unknown         yes             mixed
   extensibility           unknown         mixed           mixed
   service classes         unknown         yes             mixed
   mobility                unknown         mixed           mixed
   control proto           unknown         yes             mixed
   tunneling               unknown         yes             mixed

8.1 CATNIP Reviews

   All the reviewers felt that CATNIP is not completely specified.
   However, many of the ideas in CATNIP are innovative and a number of
   reviewers felt CATNIP shows the best vision of all of the proposals.
   The use of Network Service Attachment Point Addresses (NSAPs) is well
   thought out and the routing handles are innovative.

   While the goal of uniting three major protocol families, IP, ISO-CLNP
   and Novell IPX is laudable our consensus was that the developers had
   not developed detailed enough plans to support realizing that goal.



Bradner & Mankin                                               [Page 14]

RFC 1752                Recommendation for IPng             January 1995


   The plans they do describe suffer from the complexity of trying to be
   the union of a number of existing network protocols.  Some reviewers
   felt that CATNIP is basically maps IPv4, IPX, and SIPP addresses into
   NSAPs and, as such, does not deal with the routing problems of the
   current and future Internet.

   Additionally the reviewers felt that CATNIP has poor support for
   multicasting and mobility and does not specifically deal with such
   important topics as security and autoconfiguration.

8.2 SIPP Reviews

   Most of the reviewers, including those predisposed to other
   proposals, felt as one reviewer put it, that SIPP is an
   "aesthetically beautiful protocol well tailored to compactly satisfy
   today's known network requirements."  The SIPP Working Group has been
   the most dynamic over the last year, producing a myriad of
   documentation detailing almost all of the aspects necessary to
   produce a complete protocol description.

   The biggest problem the reviewers had with SIPP was with IPAE, SIPP's
   transition plan.  The overwhelming feeling was that IPAE is fatally
   flawed and could not be made to work reliably in an operational
   Internet.

   There was significant disagreement about the adequacy of the SIPP 64
   bit address size.  Although you can enumerate 10**15 end nodes in 64
   bits people have different views about how much inefficiency real-
   world routing plans introduce. [Huitema94]  The majority felt that 64
   bit addresses do not provide adequate space for the hierarchy
   required to meet the needs of the future Internet. In addition since
   no one has any experience with extended addressing and routing
   concepts of the type proposed in SIPP, the reviewers generally felt
   quite uncomfortable with this methodology.  The reviewers also felt
   that the design introduces some significant security issues.

   A number of reviewers felt that SIPP did not address the routing
   issue in any useful way.  In particular, there has been no serious
   attempt made at developing ways to abstract topology information or
   to aggregate information about areas of the network.

   Finally, most of the reviewers questioned the level of complexity in
   the SIPP autoconfiguration plans as well as in SIPP in general, other
   than the header itself.







Bradner & Mankin                                               [Page 15]

RFC 1752                Recommendation for IPng             January 1995


8.3 TUBA Reviews

   The reviewers generally felt that the most important thing that TUBA
   has offers is that it is based on CLNP and there is significant
   deployment of CLNP-capable routers throughout the Internet.  There
   was considerably less agreement that there was significant deployment
   of CLNP-capable hosts or actual networks running CLNP.  Another
   strong positive for TUBA is the potential for convergence of ISO and
   IETF networking standards.  A number of reviewers pointed out that,
   if TUBA were to be based on a changed CLNP then the advantage of an
   existing deployed infrastructure would be lost and that the
   convergence potential would be reduced.

   A number of aspects of CLNP were felt to be a problem by the
   reviewers including the inefficiencies introduced by the lack of any
   particular word alignment of the header fields, CLNP source route,
   the lack of a flow ID field, the lack of a protocol ID field, and the
   use of CLNP error messages in TUBA. The CLNP packet format or
   procedures would have to be modified to resolve at least some of
   these issues.

   There seems to be a profound disagreement within the TUBA community
   over the question of the ability of the IETF to modify the CLNP
   standards.  In our presentation in Houston we said that we felt that
   "clone and run" was a legitimate process.  This is also what the IAB
   proposed in "IP version 7". [IAB92]  The TUBA community has not
   reached consensus that this view is reasonable.  While many,
   including a number of the CLNP document authors, are adamant that
   this is not an issue and the IETF can make modifications to the base
   standards, many others are just as adamant that the standards can
   only be changed through the ISO standards process.  Since the
   overwhelming feeling within the IETF is that the IETF must 'own' the
   standards on which it is basing its future, this disagreement within
   the TUBA community was disquieting.

   For a number of reasons, unfortunately including prejudice in a few
   cases, the reviews of the TUBA proposals were much more mixed than
   for SIPP or CATNIP. Clearly TUBA meets the requirements for the
   ability to scale to large numbers of hosts, supports flexible
   topologies, is media independent and is a datagram protocol.  To the
   reviewers, it was less clear that TUBA met the other IPng
   requirements and these views varied widely.

   There was also disagreement over the advisability of using NSAPs for
   routing given the wide variety of NSAP allocation plans.  The
   Internet would have to restrict the use of NSAPs to those which are
   allocated with the actual underlying network topology in mind if the
   required degree of aggregation of routing information is to be



Bradner & Mankin                                               [Page 16]

RFC 1752                Recommendation for IPng             January 1995


   achieved.

8.4 Summary of Proposal Reviews

   To summarize, significant problems were seen in all three of the
   proposals. The feeling was that, to one degree or another, both SIPP
   and TUBA would work in the Internet context but each exhibited its
   own problems.  Some of these problems would have to be rectified
   before either one would be ready to replace IPv4, much less be the
   vehicle to carry the Internet into the future.  Other problems could
   be addressed over time.  CATNIP was felt to be too incomplete to be
   considered.

9. A Revised Proposal

   As mentioned above, there was considerable discussion of the
   strengths and weaknesses of the various IPng proposals during the
   IPng 'BigTen' retreat on May 19th and 20th 1994. [Knopper94b]  After
   this retreat Steve Deering and Paul Francis, two of the co-chairs of
   the SIPP Working Group, sent a message to the sipp mailing list
   detailing the discussions at the retreat and proposing some changes
   in SIPP. [Deering94a]

   The message noted "The recurring (and unsurprising) concerns about
   SIPP were:

   (1) complexity/manageability/feasibility of IPAE, and

   (2) adequacy/correctness/limitations of SIPP's addressing and routing
       model, especially the use of loose source routing to accomplish
       'extended addressing'".

   They "proposed to address these concerns by changing SIPP as follows:

   * Change address size from 8 bytes to 16 bytes (fixed-length).

   * Specify optional use of serverless autoconfiguration of the 16-byte
     address by using IEEE 802 address as the low-order ("node ID")
     part.

   * For higher-layer protocols that use internet-layer addresses as
     part of connection identifiers (e.g., TCP), require that they use
     the entire 16-byte addresses.

   * Do *not* use Route Header for extended addressing."






Bradner & Mankin                                               [Page 17]

RFC 1752                Recommendation for IPng             January 1995


   After considerable discussion on the sipp and big-internet mailing
   lists about these proposed changes, the SIPP working group published
   a revised version of SIPP [Deering94b], a new addressing architecture
   [Francis94], and a simplified transition mechanism [Gillig94a].
   These were submitted to the IPng Directorate for their consideration.

   This proposal represents a synthesis of multiple IETF efforts with
   much of the basic protocol coming from the SIPP effort, the
   autoconfiguration and transition portions influenced by TUBA, the
   addressing structure is based on the CIDR work and the routing header
   evolving out of the SDRP deliberations.

10. Assumptions

10.1 Criteria Document and Timing of Recommendation

   In making the following recommendations we are making two assumptions
   of community consensus; that the IPng criteria document represents
   the reasonable set of requirements for an IPng, and that a specific
   recommendation should be made now and that from this point on the
   IETF should proceed with a single IPng effort.

   As described above, the IPng Technical Criteria document [Kasten94]
   was developed in a open manner and was the topic of extensive
   discussions on a number of mailing lists.  We believe that there is a
   strong consensus that this document accurately reflects the
   community's set of technical requirements which an IPng should be
   able to meet.

   A prime topic of discussion on the big-internet mailing list this
   spring as well as during the open IPng directorate meeting in
   Seattle, was the need to make a specific IPng recommendation at this
   time.  Some people felt that additional research would help resolve
   some of the issues that are currently unresolved.  While others
   argued that selecting a single protocol to work on would clarify the
   picture for the community, focus the resources of the IETF on
   finalizing its details, and, since the argument that there were open
   research items could be made at any point in history, there might
   never be a 'right' time.

   Our reading of the community is that there is a consensus that a
   specific recommendation should be made now.  This is consistent with
   the views expressed during the ipdecide BOF in Amsterdam [Gross94]
   and in some of the RFC 1550 white papers [Carpen94a].

   There is no particular reason to think that the basic recommendation
   would be significantly different if we waited for another six months
   or a year.  Clearly some details which are currently unresolved could



Bradner & Mankin                                               [Page 18]

RFC 1752                Recommendation for IPng             January 1995


   be filled in if the recommendation were to be delayed, but the
   current fragmentation of the IETF's energies limits the efficiency of
   this type of detail resolution. Concentrating the resources of the
   IETF behind a single effort seems to us to be a more efficient way to
   proceed.

10.2 Address Length

   One of the most hotly discussed aspects of the IPng design
   possibilities was address size and format.  During the IPng process
   four distinct views were expressed about these issues:

   1. The view that 8 bytes of address are enough to meet the current
      and future needs of the Internet (squaring the size of the IP
      address space).  More would waste bandwidth, promote inefficient
      assignment, and cause problems in some networks (such as mobiles
      and other low speed links).

   2. The view that 16 bytes is about right.  That length supports easy
      auto-configuration as well as organizations with complex internal
      routing topologies in conjunction with the global routing topology
      now and well into the future.

   3. The view that 20 byte OSI NSAPs should be used in the interests of
      global harmonization.

   4. The view that variable length addresses which might be smaller or
      larger than 16 bytes should be used to embrace all the above
      options and more, so that the size of the address could be
      adjusted to the demands of the particular environment, and to
      ensure the ability to meet any future networking requirements.

   Good technical and engineering arguments were made for and against
   all of these views. Unanimity was not achieved, but we feel that a
   clear majority view emerged that the use of 16 byte fixed length
   addresses was the best compromise between efficiency, functionality,
   flexibility, and global applicability. [Mankin94]

11. IPng Recommendation

   After a great deal of discussion in many forums and with the
   consensus of the IPng Directorate, we recommend that the protocol
   described in "Simple Internet Protocol Plus (SIPP) Spec. (128 bit
   ver)" [Deering94b] be adopted as the basis for IPng, the next
   generation of the Internet Protocol.  We also recommend that the
   other documents listed in Appendix C be adopted as the basis of
   specific features of this protocol.




Bradner & Mankin                                               [Page 19]

RFC 1752                Recommendation for IPng             January 1995


   This proposal resolves most of the perceived problems, particularly
   in the areas of addressing, routing, transition and address
   autoconfiguration.  It includes the broad base of the SIPP proposal
   effort, flexible address autoconfiguration features, and a merged
   transition strategy.  We believe that it meets the requirements
   outlined in the IPng Criteria document and provides the framework to
   fully meet the needs of the greater Internet community for the
   foreseeable future.

11.1 IPng Criteria Document and IPng

   A detailed review of how IPng meets the requirements set down in the
   IPng Criteria document [Kasten94] will soon be published.  Following
   is our feelings about the extent to which IPng is responsive to the
   criteria.

   * complete specification - the base specifications for IPng are
     complete but transition and address autoconfiguration do remain to
     be finalized
   * architectural simplicity - the protocol is simple, easy to explain
     and uses well established paradigms
   * scale - an address size of 128 bits easily meets the need to
     address 10**9 networks even in the face of the inherent
     inefficiency of address allocation for efficient routing
   * topological flexibility - the IPng design places no constraints on
     network topology except for the limit of 255 hops
   * performance - the simplicity of processing, the alignment of the
     fields in the headers, and the elimination of the header checksum
     will allow for high performance handling of IPng data streams
   * robust service - IPng includes no inhibitors to robust service and
     the addition of packet-level authentication allows the securing of
     control and routing protocols without having to have separate
     procedures
   * transition - the IPng transition plan is simple and realistically
     covers the transition methods that will be present in the
     marketplace
   * media independence - IPng retains IPv4's media independence, it may
     be possible to make use of IPng's Flow Label in some connection-
     oriented media such as ATM
   * datagram service - IPng preserves datagram service as its basic
     operational mode, it is possible that the use of path MTU discovery
     will complicate the use of datagrams in some cases
   * configuration ease - IPng will have easy and flexible address
     autoconfiguration which will support a wide variety of environments
     from nodes on an isolated network to nodes deep in a complex
     internet
   * security - IPng includes specific mechanisms for authentication and
     encryption at the internetwork layer; the security features do rely



Bradner & Mankin                                               [Page 20]

RFC 1752                Recommendation for IPng             January 1995


     on the presence of a yet to be defined key management system
   * unique names - IPng addresses may be used as globally unique names
     although they do have topological significance
   * access to standards - all of the IPng standards will be published
     as RFCs with unlimited distribution
   * multicast support - IPng specifically includes multicast support
   * extensibility - the use of extension headers and an expandable
     header option feature will allow the introduction of new features
     into IPng when needed in a way that minimizes the disruption of the
     existing network
   * service classes - the IPng header includes a Flow Label which may
     be used to differentiate requested service classes
   * mobility - the proposed IPv4 mobility functions will work with IPng
   * control protocol - IPng includes the familiar IPv4 control protocol
     features
   * tunneling support - encapsulation of IPng or other protocols within
     IPng is a basic capability described in the IPng specifications

11.2 IPv6

   The IANA has assigned version number 6 to IPng.  The protocol itself
   will be called IPv6.

   The remainder of this memo is used to describe IPv6 and its features.
   This description is an overview snapshot.  The standards documents
   themselves should be referenced for definitive specifications.  We
   also make a number of specific recommendations concerning the details
   of the proposed protocol, the procedures required to complete the
   definition of the protocol, and the IETF working groups we feel are
   necessary to accomplish the task.

12. IPv6 Overview

   IPv6 is a new version of the Internet Protocol, it has been designed
   as an evolutionary, rather than revolutionary, step from IPv4.
   Functions which are generally seen as working in IPv4 were kept in
   IPv6.  Functions which don't work or are infrequently used were
   removed or made optional.  A few new features were added where the
   functionality was felt to be necessary.

   The important features of IPv6 include: [Hinden94c]

   * expanded addressing and routing capabilities - The IP address size
     is increased from 32 bits to 128 bits providing support for a much
     greater number of addressable nodes, more levels of addressing
     hierarchy, and simpler auto-configuration of addresses.





Bradner & Mankin                                               [Page 21]

RFC 1752                Recommendation for IPng             January 1995


     The scaleability of multicast routing is improved by adding a
     "scope" field to multicast addresses.

     A new type of address, called a "cluster address" is defined to
     identify topological regions rather than individual nodes.  The use
     of cluster addresses in conjunction with the IPv6 source route
     capability allows nodes additional control over the path their
     traffic takes.

   * simplified header format - Some IPv4 header fields have been
     dropped or made optional to reduce the common-case processing cost
     of packet handling and to keep the bandwidth overhead of the IPv6
     header as low as possible in spite of the increased size of the
     addresses.  Even though the IPv6 addresses are four time longer
     than the IPv4 addresses, the IPv6 header is only twice the size of
     the IPv4 header.

   * support for extension headers and options - IPv6 options are placed
     in separate headers that are located in the packet between the IPv6
     header and the transport-layer header.  Since most IPv6 option
     headers are not examined or processed by any router along a
     packet's delivery path until it arrives at its final destination,
     this organization facilitates a major improvement in router
     performance for packets containing options.  Another improvement is
     that unlike IPv4, IPv6 options can be of arbitrary length and not
     limited to 40 bytes. This feature plus the manner in which they are
     processed, permits IPv6 options to be used for functions which were
     not practical in IPv4.

     A key extensibility feature of IPv6 is the ability to encode,
     within an option, the action which a router or host should perform
     if the option is unknown. This permits the incremental deployment
     of additional functionality into an operational network with a
     minimal danger of disruption.

   * support for authentication and privacy - IPv6 includes the
     definition of an extension which provides support for
     authentication and data integrity. This extension is included as a
     basic element of IPv6 and support for it will be required in all
     implementations.

     IPv6 also includes the definition of an extension to support
     confidentiality by means of encryption.  Support for this extension
     will be strongly encouraged in all implementations.







Bradner & Mankin                                               [Page 22]

RFC 1752                Recommendation for IPng             January 1995


   * support for autoconfiguration - IPv6 supports multiple forms of
     autoconfiguration, from "plug and play" configuration of node
     addresses on an isolated network to the full-featured facilities
     offered by DHCP.

   * support for source routes - IPv6 includes an extended function
     source routing header designed to support the Source Demand Routing
     Protocol (SDRP). The purpose of SDRP is to support source-initiated
     selection of routes to complement the route selection provided by
     existing routing protocols for both inter-domain and intra-domain
     routes. [Estrin94b]

   * simple and flexible transition from IPv4 - The IPv6 transition plan
     is aimed at meeting four basic requirements: [Gillig94a]

     - Incremental upgrade.  Existing installed IPv4 hosts and routers
       may be upgraded to IPv6 at any time without being dependent on
       any other hosts or routers being upgraded.
     - Incremental deployment.  New IPv6 hosts and routers can be
       installed at any time without any prerequisites.
     - Easy Addressing.  When existing installed IPv4 hosts or routers
       are upgraded to IPv6, they may continue to use their existing
       address.  They do not need to be assigned new addresses.
     - Low start-up costs.  Little or no preparation work is needed in
       order to upgrade existing IPv4 systems to IPv6, or to deploy new
       IPv6 systems.

   * quality of service capabilities - A new capability is added to
     enable the labeling of packets belonging to particular traffic
     "flows" for which the sender has requested special handling, such
     as non-default quality of service or "real-time" service.




















Bradner & Mankin                                               [Page 23]

RFC 1752                Recommendation for IPng             January 1995


12.1 IPv6 Header Format

   The IPv6 header, although longer than the IPv4 header, is
   considerably simplified.  A number of functions that were in the IPv4
   header have been relocated in extension headers or dropped.
   [Deering94b]

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|                       Flow Label                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Payload Length        |  Next Header  |   Hop Limit   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         Source Address                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                      Destination Address                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   * Version - Internet Protocol version number. IPng has been assigned
     version number 6. (4-bit field)

   * Flow Label - This field may be used by a host to label those
     packets for which it is requesting special handling by routers
     within a network, such as non-default quality of service or "real-
     time" service. (28-bit field)

   * Payload Length - Length of the remainder of the packet following
     the IPv6 header, in octets. To permit payloads of greater than 64K
     bytes, if the value in this field is 0 the actual packet length
     will be found in an Hop-by-Hop option. (16-bit unsigned integer)

   * Next Header - Identifies the type of header immediately following
     the IPv6 header.  The Next Header field uses the same values as the
     IPv4 Protocol field (8-bit selector field)






Bradner & Mankin                                               [Page 24]

RFC 1752                Recommendation for IPng             January 1995


   * Hop Limit - Used to limit the impact of routing loops. The Hop
     Limit field is decremented by 1 by each node that forwards the
     packet.  The packet is discarded if Hop Limit is decremented to
     zero. (8-bit unsigned integer)

   * Source Address - An address of the initial sender of the packet.
     (128 bit field)

   * Destination Address - An address of the intended recipient of the
     packet (possibly not the ultimate recipient, if an optional Routing
     Header is present). (128 bit field)

12.2 Extension Headers

   In IPv6, optional internet-layer information is encoded in separate
   headers that may be placed between the IPv6 header and the
   transport-layer header in a packet.  There are a small number of such
   extension headers, each identified by a distinct Next Header value.
   [From a number of the documents listed in Appendix C.]

   12.2.1 Hop-by-Hop Option Header

      The Hop-by-Hop Options header is used to carry optional
      information that must be examined by every node along a packet's
      delivery path.  The Hop-by-Hop Options header is identified by a
      Next Header value of 0 in the IPv6 header, and has the following
      format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |  Hdr Ext Len  |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      .                                                               .
      .                            Options                            .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      * Next Header - Identifies the type of header immediately
        following the Hop-by-Hop Options header.  Uses the same values
        as the IPv4 Protocol field. (8-bit selector)

      * Hdr Ext Len - Length of the Hop-by-Hop Options header in 8-octet
        units, not including the first 8 octets. (8-bit unsigned
        integer)






Bradner & Mankin                                               [Page 25]

RFC 1752                Recommendation for IPng             January 1995


      * Options - Contains one or more TLV-encoded options. (Variable-
        length field, of length such that the complete Hop-by-Hop
        Options header is an integer multiple of 8 octets long.)

   12.2.2 IPv6 Header Options

      Two of the currently-defined extension headers -- the Hop-by-Hop
      Options header and the End-to-End Options header -- may carry a
      variable number of Type-Length-Value (TLV) encoded "options", of
      the following format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  Option Type  |  Opt Data Len |  Option Data
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      * Option Type - identifier of the type of option (8-bit field)

      * Opt Data Len - Length of the Option Data field of this option,
        in octets. (8-bit unsigned integer)

      * Option Data - Option-Type-specific data. (Variable-length field)

      The Option Type identifiers are internally encoded such that their
      highest-order two bits specify the action that must be taken if
      the processing IPv6 node does not recognize the Option Type:

      00 - skip over this option and continue processing the header
      01 - discard the packet
      10 - discard the packet and send an ICMP Unrecognized Type message
            to the packet's Source Address, pointing to the unrecognized
            Option Type
      11 - undefined.

      In the case of Hop-by-Hop options only, the third-highest-order
      bit of the Option Type specifies whether or not the Option Data of
      this option shall be included in the integrity assurance
      computation performed when an Authentication header is present.
      Option data that changes en route must be excluded from that
      computation.












Bradner & Mankin                                               [Page 26]

RFC 1752                Recommendation for IPng             January 1995


   12.2.3 Routing Header

      The Routing header is used by an IPv6 source to list one or more
      intermediate nodes (or topological clusters) to be "visited" on
      the way to a packet's destination.  This particular form of the
      Routing Header is designed to support SDRP. [Estrin94b]

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Next Header   |Routing Type=1 |M|F| Reserved   | SrcRouteLen  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NextHopPtr    |            Strict/Loose Bit Mask              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                         Source Route                          .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      * Next Header - Identifies the type of header immediately
        following the Routing Header.  Uses the same values as the IPv4
        Protocol field. (8-bit selector)

      * Routing Type - Indicates the type of routing supported by this
        header.  Value must be 1.

      * MRE flag - Must Report Errors. If this bit is set to 1, and a
        router can not further forward a packet (with an incompletely
        traversed source route), as specified in the Source Route, the
        router must generate an ICMP error message. If this bit is set
        to 0, and a router can not further forward a packet (with an
        incompletely traversed source route), as specified in the Source
        Route, the router should not generate an ICMP error message.

      * F flag -  Failure of Source Route Behavior.  If this bit it set
        to 1, it indicates that if a router can not further forward a
        packet (with an incompletely traversed source route), as
        specified in the Source Route, the router must set the value of
        the Next Hop Pointer field to the value of the Source Route
        Length field, so that the subsequent forwarding will be based
        solely on the destination address. If this bit is set to 0, it
        indicates that if a router can not further forward a packet
        (with an incompletely traversed source route), as specified in
        the Source Route, the router must discard the packet.





Bradner & Mankin                                               [Page 27]

RFC 1752                Recommendation for IPng             January 1995


      * Reserved - Initialized to zero for transmission; ignored on
        reception.

      * SrcRouteLen - Source Route Length - Number of source route
        elements/hops in the SDRP Routing header.  Length of SDRP
        routing header can be calculated from this value (length =
        SrcRouteLen * 16 + 8) This field may not exceed a value of 24.
        (8 bit unsigned integer)

      * NextHopPtr - Next Hop Pointer- Index of next element/hop to be
        processed; initialized to 0 to point to first element/hop in the
        source route.  When Next Hop Pointer is equal to Source Route
        Length then the Source Route is completed.  (8 bit unsigned
        integer)

      * Strict/Loose Bit Mask - The Strict/Loose Bit Mask is used when
        making a forwarding decision. If the value of the Next Hop
        Pointer field is N, and the N-th bit in the Strict/Loose Bit
        Mask field is set to 1, it indicates that the next hop is a
        Strict Source Route Hop. If this bit is set to 0, it indicates
        that the next hop is a Loose Source Route Hop. (24 bit
        bitpattern)

      * Source Route - A list of IPv6 addresses indicating the path that
        this packet should follow.  A Source Route can contain an
        arbitrary intermix of unicast and cluster addresses. (integral
        multiple of 128 bits)

   12.2.4 Fragment Header

      The Fragment header is used by an IPv6 source to send payloads
      larger than would fit in the path MTU to their destinations.
      (Note: unlike IPv4, fragmentation in IPv6 is performed only by
      source nodes, not by routers along a packet's delivery path)  The
      Fragment header is identified by a Next Header value of 44 in the
      immediately preceding header, and has the following format:


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Identification                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      * Next Header - Identifies the type of header immediately
        following the Fragment header.  Uses the same values as the IPv4
        Protocol field. (8 bit selector)




Bradner & Mankin                                               [Page 28]

RFC 1752                Recommendation for IPng             January 1995


      * Reserved, Res - Initialized to zero for transmission; ignored on
        reception.

      * Fragment Offset - The offset, in 8-octet units, of the following
        payload, relative to the start of the original, unfragmented
        payload. (13-bit unsigned integer)

      * M flag - 1 = more fragments; 0 = last fragment.

      * Identification - A value assigned to the original payload that
        is different than that of any other fragmented payload sent
        recently with the same IPv6 Source Address, IPv6 Destination
        Address, and Fragment Next Header value.  (If a Routing header
        is present, the IPv6 Destination Address is that of the final
        destination.)  The Identification value is carried in the
        Fragment header of all of the original payload's fragments, and
        is used by the destination to identify all fragments belonging
        to the same original payload.  (32 bit field)

   12.2.5 Authentication Header

      The Authentication header is used to provide authentication and
      integrity assurance for IPv6 packets.  Non-repudiation may be
      provided by an authentication algorithm used with the
      Authentication header, but it is not provided with all
      authentication algorithms that might be used with this header.
      The Authentication header is identified by a Next Header value of
      51 in the immediately preceding header, and has the following
      format:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header  | Auth Data Len |            Reserved           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Security Association ID                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                      Authentication Data                      .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      * Next Header - Identifies the type of header immediately
        following the Authentication header.  Uses the same values as
        the IPv4 Protocol field. (8-bit selector)

      * Auth Data Len - Length of the Authentication Data field in 8-
        octet units. (8-bit unsigned integer)



Bradner & Mankin                                               [Page 29]

RFC 1752                Recommendation for IPng             January 1995


      * Reserved - Initialized to zero for transmission; ignored on
        reception.

      * Security Assoc. ID - When combined with the IPv6 Source Address,
        identifies to the receiver(s) the pre-established security
        association to which this packet belongs. (32 bit field)

      * Authentication Data -   Algorithm-specific information required
        to authenticate the source of the packet and assure its
        integrity, as specified for the pre-established security
        association. (Variable-length field, an integer multiple of 8
        octets long.)

   12.2.6 Privacy Header

      The Privacy Header seeks to provide confidentiality and integrity
      by encrypting data to be protected and placing the encrypted data
      in the data portion of the Privacy Header.  Either a transport-
      layer (e.g., UDP or TCP) frame may be encrypted or an entire IPv6
      datagram may be encrypted, depending on the user's security
      requirements.  This encapsulating approach is necessary to provide
      confidentiality for the entire original datagram.  If present, the
      Privacy Header is always the last non-encrypted field in a packet.

      The Privacy Header works between hosts, between a host and a
      security gateway, or between security gateways.  This support for
      security gateways permits trustworthy networks to exist without
      the performance  and monetary costs of security, while providing
      security for traffic transiting untrustworthy network segments.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Security Association Identifier (SAID)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                    Initialization Vector                      .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Next Header* |   Length*   |          Reserved*              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Protected Data*     +-+-+-+-+-+-+-+-+-+-+
      |                                           |     trailer*      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                                             *encrypted






Bradner & Mankin                                               [Page 30]

RFC 1752                Recommendation for IPng             January 1995


      * Security Association Identifier (SAID) - Identifies the security
        association for this datagram.  If no security association has
        been established, the value of this field shall be 0x0000.  A
        security  association is normally one-way. An authenticated
        communications session between two hosts will normally have two
        SAIDs in use (one in each direction).  The receiving host uses
        the combination of SAID value and originating address to
        distinguish the correct association. (32 bit value)

      * Initialization Vector -  This field is optional and its value
        depends on the SAID in use.  For example, the field may contain
        cryptographic synchronization data for a block oriented
        encryption algorithm. It may also be used to contain a
        cryptographic initialization vector.  A Privacy Header
        implementation will normally use the SAID value to determine
        whether this field is present and, if it is, the field's size
        and use. (presence and length dependent on SAID)

      * Next Header - encrypted - Identifies the type of header
        immediately following the Privacy header.  Uses the same values
        as the IPv4 Protocol field. (8 bit selector)

      * Reserved - encrypted - Ignored on reception.

      * Length - encrypted - Length of the Privacy Header in 8-octet
        units, not including the first 8 octets. (8-bit unsigned
        integer)

      * Protected Data - encrypted -  This field may contain an entire
        encapsulated IPv6 datagram, including the IPv6 header, a
        sequence of zero or more IPv6 options, and a transport-layer
        payload, or it may just be a sequence of zero or more IPv6
        options followed by a transport-layer payload.  (variable
        length)

      * trailer (Algorithm-dependent Trailer) - encrypted - A field
        present to support some algorithms which need to have padding
        (e.g., to a full cryptographic block size for block-oriented
        encryption algorithms) or for storage of authentication data for
        use with a encryption algorithm that provides confidentiality
        without authentication.  It is present only when the algorithm
        in use requires such a field. (presence and length dependent on
        SAID)








Bradner & Mankin                                               [Page 31]

RFC 1752                Recommendation for IPng             January 1995


   12.2.7 End-to-End Option Header

      The End-to-End Options header is used to carry optional
      information that needs to be examined only by a packet's
      destination node(s).  The End-to-End Options header is identified
      by a Next Header value of TBD in the immediately preceding header,
      and has the same format as the Hop-by-Hop Option Header except for
      the ability to exclude an option from the authentication integrity
      assurance computation.

13. IPng Working Group

   We recommend that a new IPng Working Group be formed to produce
   specifications for the core functionality of the IPv6 protocol suite.
   The working group will carry out the recommendations of the IPng Area
   Directors as outlined at the July 1994 IETF and in this memo.  We
   recommend that this working group be chaired by Steve Deering of
   Xerox PARC and Ross Callon of Wellfleet.

   The primary task of the working group is to produce a set of
   documents that define the basic functions, interactions, assumptions,
   and packet formats for IPv6.  We recommend that Robert Hinden of Sun
   Microsystems be the editor for these documents.  The documents listed
   in Appendix C will be used by the working group to form the basis of
   the final document set.

   The work of the IPng Working Group includes:

   * complete the IPv6 overview document
   * complete the IPv6 detailed operational specification
   * complete the IPv6 Addressing Architecture specification
   * produce specifications for IPv6 encapsulations over various media
   * complete specifications for the support of packets larger than 64KB
   * complete specifications of the DNS enhancements required to support
     IPv6
   * complete specification of ICMP, IGMP and router discovery for
     support of IPv6.
   * complete specification of path MTU discovery for IPv6
   * complete specifications of IPv6 in IPv6 tunneling
   * complete the suggested address format and assignment plan
   * coordinate with the Address Autoconfiguration Working Group
   * coordinate with the NGTRANS and TACIT Working Groups
   * complete specifications of authentication and privacy support
     headers







Bradner & Mankin                                               [Page 32]

RFC 1752                Recommendation for IPng             January 1995


   The working group should also consider a few selected enhancements
   including:

   * consider ways to compress the IPv6 header in the contexts of native
     IPv6, multiple IPv6 packets in a flow, and encapsulated IPv6
   * consider specifying support for a larger minimum MTU

14. IPng Reviewer

   Currently it is the task of the IPng Area Directors, the IPng
   Directorate and the chairs of the proposed ipng working group to
   coordinate the activities of the many parallel efforts currently
   directed towards different aspects of IPng.  While this is possible
   and currently seems to be working well it can not be maintained over
   the long run because, among other reasons, the IPng Area will be
   dissolved eventually and its Directorate disbanded.  It will also
   become much more difficult as IPng related activities start up in
   other IETF areas.

   We recommend that an IPng Reviewer be appointed to be specifically
   responsible for ensuring that a consistent view of IPv6 is maintained
   across the related working groups.  We feel that this function is
   required due to the complex nature of the interactions between the
   parts of the IPng effort and due to the distribution of the IPng
   related work amongst a number of IETF areas.  We recommend that Dave
   Clark of MIT be offered this appointment.

   This would be a long-term task involving the review of on-going
   activities. The aim is not for the IPng Reviewer to make
   architectural decisions since that is the work of the various working
   groups, the IAB, and the IETF as a whole.. The aim is to spot gaps or
   misunderstandings before they reach the point where functionality or
   interworkability is threatened.

15. Address Autoconfiguration

   As data networks become more complex the need to be able to bypass at
   least some of the complexity and move towards "plug and play" becomes
   ever more acute.  The user can not be expected to be able to
   understand the details of the network architecture or know how to
   configure the network software in their host.  In the ideal case, a
   user should be able to unpack a new computer, plug it into the local
   network and "just" have it work without requiring the entering of any
   special information.  Security concerns may restrict the ability to
   offer this level of transparent address autoconfiguration in some
   environments but the mechanisms must be in place to support whatever
   level of automation which the local environment feels comfortable
   with.



Bradner & Mankin                                               [Page 33]

RFC 1752                Recommendation for IPng             January 1995


   The basic requirement of "plug and play" operation is that a host
   must be able to acquire an address dynamically, either when attaching
   to a network for the first time or when the host needs to be
   readdressed because the host moved or because the identity of the
   network has changed.  There are many other functions required to
   support a full "plug and play" environment. [Berk94] Most of these
   must be addressed outside of the IPv6 Area but a focused effort to
   define a host address autoconfiguration protocol is part of the IPv6
   process.

   We recommend that a new Address Autoconfiguration Working Group
   (addrconf) be formed with Dave Katz of Cisco Systems and Sue Thomson
   of Bellcore as co-chairs. The purpose of this working group is to
   design and specify a protocol for allocating addresses dynamically to
   IPv6 hosts.  The address configuration protocol must be suitable for
   a wide range of network topologies, from a simple isolated network to
   a sophisticated globally connected network. It should also allow for
   varying levels of administrative control, from completely automated
   operation to very tight oversight.

   The scope of this working group is to propose a host address
   autoconfiguration protocol which supports the full range of
   topological and administrative environments in which IPv6 will be
   used.  It is the intention that, together with IPv6 system discovery,
   the address autoconfiguration protocol will provide the minimal
   bootstrapping information necessary to enable hosts to acquire
   further configuration information (such as that provided by DHCP in
   IPv4). The scope does not include router configuration or any other
   host configuration functions. However, it is within the scope of the
   working group to investigate and document the interactions between
   this work and related functions including system discovery, DNS
   autoregistration, service discovery, and broader host configuration
   issues, to facilitate the smooth integration of these functions.
   [Katz94a]

   The working group is expected to complete its work around the end of
   1994 and disband at that time.  The group will use "IPv6 Address
   Autoconfiguration Architecture" [Katz94b] draft document as the basis
   of their work.

16. Transition

   The transition of the Internet from IPv4 to IPv6 has to meet two
   separate needs.  There is a short term need to define specific
   technologies and methods to transition IPv4 networks, including the
   Internet, into IPv6 networks and an IPv6 Internet.  There is also a
   long term need to do broad-based operational planning for transition,
   including developing methods to allow decentralized migration



Bradner & Mankin                                               [Page 34]

RFC 1752                Recommendation for IPng             January 1995


   strategies, understanding the ramifications of a long period of
   coexistence when both protocols are part of the basic infrastructure,
   developing an understanding of the type and scope of architectural
   and interoperability testing that will be required to ensure a
   reliable and manageable Internet in the future.

16.1 Transition - Short Term

   Any IPng transition plan must take into account the realities of what
   types of devices vendors will build and network managers will deploy.
   The IPng transition plan must define the procedures required to
   successfully implement the functions which vendors will be likely to
   include in their devices.  This is the case even if there are good
   arguments to recommend against a particular function, header
   translation for example.  If products will exist it is better to have
   them interoperate than not.

   We recommend that a new IPng Transition (NGTRANS) Working Group be
   formed with Bob Gilligan of Sun Microsystems and xxx of yyy as co-
   chairs to design the mechanisms and procedures to support the
   transition of the Internet from IPv4 to IPv6 and to give advice on
   what procedures and techniques are preferred.

   The work of the group will fall into three areas:

   * Define the processes by which the Internet will make the transition
     from IPv4 to IPv6.  As part of this effort, the group will produce
     a document explaining to the general Internet community what
     mechanisms will be employed in the transition, how the transition
     will work, the assumptions about infrastructure deployment inherent
     in the operation of these mechanisms, and the types of
     functionality that applications developers will be able to assume
     as the protocol mix changes over time.
   * Define and specify the mandatory and optional mechanisms that
     vendors should implement in hosts, routers, and other components of
     the Internet in order for the transition to be carried out. Dual-
     stack, encapsulation and header translation mechanisms must all be
     defined, as well as the interaction between hosts using different
     combinations of these mechanisms.  The specifications produced will
     be used by people implementing these IPv6 systems.
   * Articulate a concrete operational plan for the Internet to make the
     transition from IPv4 to IPv6.  The result of this work will be a
     transition plan for the Internet that network operators and
     Internet subscribers can execute.
                                                             [Gillig94c]






Bradner & Mankin                                               [Page 35]

RFC 1752                Recommendation for IPng             January 1995


   The working group is expected to complete its work around the end of
   1994 and disband at that time.  The group will use the "Simple SIPP
   Transition (SST)" [Gilig94a] overview document as the starting point
   for its work.

16.2 Transition - Long Term

   There are a number of transition related topics in addition to
   defining the specific IPv4 to IPv6 mechanisms and their deployment,
   operation and interaction.  The ramifications and procedures of
   migrating to a new technology or to a new version of an existing
   technology must be fully understood.

   We recommend that the Transition and Coexistence Including Testing
   (TACIT) Working Group, which was started a few months ago, explore
   some of the basic issues associated with the deployment of new
   technology into an established Internet.  The TACIT Working Group
   will focus on the generic issues of transition and will not limit
   itself to the upcoming transition to IPv6 because, over time,
   enhancements to IPv6 (IPv6ng) will be developed and accepted.  At
   that point they will need to be deployed into the then existing
   Internet.  The TACIT Working Group will be more operationally
   oriented than the NGTRANS Working Group and will continue well into
   the actual IPv6 transition.

   The main areas of exploration are:

   * Make the transition from a currently deployed protocol to a new
     protocol while accommodating heterogeneity and decentralized
     management.
   * Since it is often difficult or impossible to replace all legacy
     systems or software, it is important to understand the
     characteristics and operation of a long period of coexistence
     between a new protocol and the existing protocol.
   * The Internet must now be considered a utility.  We are far removed
     from a time when a new technology could be deployed to see if it
     would work in large scale situations.  Rigorous architectural and
     interoperability testing must be part of the predeployment phase of
     any proposed software for the Internet. Testing the scaling up
     behaviors and robustness of a new protocol will offer particular
     challenges. The WG should determine if there are lessons to be
     learned from:  OSPF, BGP4 and CIDR Deployment, the AppleTalk 1 to 2
     transition, DECnet Phase 4 to Phase 5 planning and transition,
     among others.







Bradner & Mankin                                               [Page 36]

RFC 1752                Recommendation for IPng             January 1995


   The TACIT Working Group will explore each of these facets of the
   deployment of new technology and develop a number of documents to
   help guide users and managers of affected data networks and provide
   to the IETF:

   * Detailed descriptions of problem areas in transition and
     coexistence, both predicted, based on lessons learned, and observed
     as the IPv6 process progresses.
   * Recommendations for specific testing procedures.
   * Recommendations for coexistence operations procedures
   * Recommendations for the smoothing of decentralized transition
     planning.
                                                         [Huston94]

17. Other Address Families

   There are many environments in which there are one or more network
   protocols already deployed or where a significant planning effort has
   been undertaken to create a comprehensive network addressing plan. In
   such cases there may be a temptation to integrate IPv6 into the
   environment by making use of an existing addressing plan to define
   all or part of the IPv6 addresses.  The advantage of doing this is
   that it permits unified management of address space among multiple
   protocol families.  The use of common addresses can help facilitate
   transition from other protocols to IPv6.

   If the existing addresses are globally unique and assigned with
   regard to network topology this may be a reasonable idea.  The IETF
   should work with other organizations to develop algorithms that could
   be used to map addresses between IPv6 and other environments.  The
   goal for any such mapping must be to provide an unambiguous 1 to 1
   map between individual addresses.

   Suggestions have been made to develop mapping algorithms for Novell
   IPX addresses, some types of OSI NSAPs, E164 addresses and SNA
   addresses.  Each of these possibilities should be carefully examined
   to ensure that use of such an algorithm solves more problems than it
   creates.  In some cases it may be better to recommend either that a
   native IPng addressing plan be developed instead, or that an IPv6
   address be used within the non-IP environment. [Carpen94b]

   We recommend that, in conjunction with other organizations,
   recommendations about the use of non-IPv6 addresses in IPv6
   environments and IPv6 addresses in non-IPv6 environments be
   developed.






Bradner & Mankin                                               [Page 37]

RFC 1752                Recommendation for IPng             January 1995


18. Impact on Other IETF Standards

   Many current IETF standards are affected by IPv6.  At least 27 of the
   current 51 full Internet Standards must be revised for IPv6, along
   with at least 6 of the 20 Draft Standards and at least 25 of the 130
   Proposed Standards. [Postel94]

   In some cases the revisions consist of simple changes to the text,
   for example, in a number of RFCs an IP address is referred to in
   passing as a "32 bit IP address" even though IP addresses are not
   directly used in the protocol being defined.  All of the standards
   track documents will have to be checked to see if they contain such
   references.

   In most of the rest of the cases revisions to the protocols,
   including packet formats, will be required.  In many of these cases
   the address is just being carried as a data element and a revised
   format with a larger field for the address will have no effect on the
   functional paradigm.

   In the remaining cases some facet of the operation of the protocol
   will be changed as a result of IPv6.  For example, the security and
   source route mechanisms are fundamentally changed from IPv4 with
   IPv6.  Protocols and applications that relied on the IPv4
   functionality will have to be redesigned or rethought to use the
   equivalent function in IPv6.

   In a few cases this opportunity should be used to determine if some
   of the RFCs should be moved to historic, for example EGP [Mills84]
   and IP over ARCNET. [Provan91]

   The base IPng Working Group will address some of these, existing IETF
   working groups can work on others, while new working groups must be
   formed to deal with a few of them. The IPng Working Group will be
   responsible for defining new versions of ICMP, ARP/RARP, and UDP.  It
   will also review RFC 1639, "FTP Operation Over Big Address Records
   (FOOBAR)" [Piscit94] and RFC 1191 "Path MTU Discovery" [Mogul90]

   Existing working groups will examine revisions for some of the
   routing protocols: RIPv2, IS-IS, IDRP and SDRP.  A new working group
   may be required for OSPF.

   The existing DHCP Working Group may be able to revise DHCP and
   examine BOOTP.







Bradner & Mankin                                               [Page 38]

RFC 1752                Recommendation for IPng             January 1995


   A TCPng Working Group will be formed soon, and new working groups
   will have to be formed to deal with standards such as SNMP, DNS, NTP,
   NETbios, OSI over TCP, Host Requirements, and Kerberos as well as
   reviewing most of the RFCs that define IP usage over various media.

   In addition to the standards track RFCs mentioned above there are
   many Informational and Experimental RFCs which would be affected as
   well as numerous Internet Drafts (and those standards track RFCs that
   we missed).

   We recommend that the IESG commission a review of all standards track
   RFCs to ensure that a full list of affected documents is compiled. We
   recommend that the IESG charge current IETF working groups with the
   task of understanding the impact of IPv6 on their proposals and,
   where appropriate, revise the documents to include support for IPv6.

   We recommend that the IESG charter new working groups where required
   to revise other standards RFCs.

19. Impact on non-IETF standards and on products

   Many products and user applications which rely on the size or
   structure of IPv4 addresses will need to be modified to work with
   IPv6.  While the IETF can facilitate an investigation of the impacts
   of IPv6 on non-IETF standards and products, the primary
   responsibility for doing so resides in the other standards bodies and
   the vendors.

   Examples of non-IETF standards that are effected by IPv6 include the
   POSIX standards, Open Software Foundation's DCE and DME, X-Open, Sun
   ONC, the Andrew File System and MIT's Kerberos.  Most products that
   provide specialized network security including firewall-type devices
   are among those that must be extended to support IPv6.

20. APIs

   It is traditional to state that the IETF does not "do" APIs.  While
   there are many reasons for this, the one most commonly referenced is
   that there are too many environments where TCP/IP is used, too many
   different operating systems, programming languages, and platforms.
   The feeling is that the IETF should not get involved in attempting to
   define a language and operating system independent interface in the
   face of such complexity.

   We feel that this historical tendency for the IETF to avoid dealing
   with APIs should be reexamined in the case of IPv6.  We feel that in
   a few specific cases the prevalence of a particular type of API is
   such that  a single common solution for the modifications made



Bradner & Mankin                                               [Page 39]

RFC 1752                Recommendation for IPng             January 1995


   necessary by IPv6 should be documented.

   We recommend that Informational RFCs be solicited or developed for
   these few cases.  In particular, the Berkeley-style sockets
   interface, the UNIX TLI and XTI interfaces, and the WINSOCK
   interfaces should be targeted.  A draft document exists which could
   be developed into the sockets API description. [Gillig94b]

21. Future of the IPng Area and Working Groups

   In our presentation at the Houston IETF meeting we stated that the
   existing IPng proposal working groups would not be forced to close
   down after the recommendation was made.  Each of them has been
   working on technologies that may have applications in addition to
   their IPng proposal and these technologies should not be lost.

   Since the Toronto IETF meeting the existing IPng working groups have
   been returned to the Internet Area.  The group members may decide to
   close down the working groups or to continue some of their efforts.
   The charters of the working groups must be revised if they choose to
   continue since they would no longer be proposing an IPng candidate.

   In Toronto the chairs of the SIPP Working Group requested that the
   SIPP Working Group be concluded.  The chairs of the TUBA Working
   Group requested that the TUBA working group be understood to be in
   hiatus until a number of the documents in process were completed, at
   which time they would request that the working group be concluded.

   We recommend that the IPng Area and its Directorate continue until
   the basic documents have entered the standards track in late 1994 or
   early 1995 and that after such time the area be dissolved and those
   IPng Area working groups still active be moved to their normal IETF
   areas.

22. Security Considerations

   The security of the Internet has long been questioned.  It has been
   the topic of much press coverage, many conferences and workshops.
   Almost all of this attention has been negative, pointing out the many
   places where the level of possible security is far less than that
   deemed necessary for the current and future uses of the Internet. A
   number of the RFC 1550 White Papers specifically pointed out the
   requirement to improve the level of security available [Adam94,
   Bell94b, Brit94, Green94, Vecchi94, Flei94] as does "Realizing the
   Information Future". [Nat94]






Bradner & Mankin                                               [Page 40]

RFC 1752                Recommendation for IPng             January 1995


   In February of 1994, the IAB convened a workshop on security in the
   Internet architecture.  The report of this workshop [IAB94] includes
   an exploration of many of the security problem areas and makes a
   number of recommendations to improve the level of security that the
   Internet offers its users.

   We feel that an improvement in the basic level of security in the
   Internet is vital to its continued success.  Users must be able to
   assume that their exchanges are safe from tampering, diversion and
   exposure.  Organizations that wish to use the Internet to conduct
   business must be able to have a high level of confidence in the
   identity of their correspondents and in the security of their
   communications.  The goal is to provide strong protection as a matter
   of course throughout the Internet.

   As the IAB report points out, many of the necessary tools are not a
   function of the internetworking layer of the protocol.  These higher
   level tools could make use of strong security features in the
   internetworking layer if they were present. While we expect that
   there will be a number of special high-level security packages
   available for specific Internet constituencies, support for basic
   packet-level authentication will provide for the adoption of a much
   needed, widespread, security infrastructure throughout the Internet.

   It is best to separate the support for authentication from the
   support for encryption.  One should be able to use the two functions
   independently.  There are some applications in which authentication
   of a corespondent is sufficient and others where the data exchanged
   must be kept private.

   It is our recommendation that IPv6 support packet authentication as a
   basic and required function.  Applications should be able to rely on
   support for this feature in every IPv6 implementation.  Support for a
   specific authentication algorithm should also be mandated while
   support for additional algorithms should be optional.

   Thus we recommend that support for the Authentication Header be
   required in all compliant IPv6 implementations.

   We recommend that support for a specific authentication algorithm be
   required.  The specific algorithm should be determined by the time
   the IPv6 documents are offered as Proposed Standards.

   We recommend that support for the Privacy Header be required in IPv6
   implementations.






Bradner & Mankin                                               [Page 41]

RFC 1752                Recommendation for IPng             January 1995


   We recommend that support for a privacy authentication algorithm be
   required. The specific algorithm should be determined by the time the
   IPv6 documents are offered as Proposed Standards.

   Clearly, a key management infrastructure will be required in order to
   enable the use of the authentication and encryption headers.
   However, defining such an infrastructure is outside the scope of the
   IPv6 effort.  We do note that there are on-going IETF activities in
   this area. The IPv6 transition working groups must coordinate with
   these activities.

   Just as clearly, the use of authentication and encryption may add to
   the cost and impact the performance of systems but the more secure
   infrastructure is worth the penalty.  Whatever penalty there is
   should also decrease in time with improved software and hardware
   assistance.

   The use of firewalls is increasing on the Internet.  We hope that the
   presence of the authentication and privacy features in IPv6 will
   reduce the need for firewalls, but we do understand that they will
   continue to be used for the foreseeable future.  In this light, we
   feel that clear guidance should be given to the developers of
   firewalls on the best ways to design and configure them when working
   in an IPv6 environment.

   We recommend that an "IPv6 framework for firewalls" be developed.
   This framework should explore the ways in which the Authentication
   Header can be used to strengthen firewall technology and detail how
   the IPv6 packet should be analyzed by a firewall.

   Some aspects of security require additional study.  For example, it
   has been pointed out [Vecchi94] that, even in non-military
   situations, there are places where procedures to thwart traffic
   analysis will be required.  This could be done by the use of
   encrypted encapsulation, but this and other similar requirements must
   be addressed on an on-going basis by the Security Area of the IETF.
   The design of IPv6 must be flexible enough to support the later
   addition of such security features.

   We believe that IPv6 with its inherent security features will provide
   the foundation upon which the Internet can continue to expand its
   functionality and user base.









Bradner & Mankin                                               [Page 42]

RFC 1752                Recommendation for IPng             January 1995


23. Authors' Addresses

   Scott Bradner
   Harvard University
   10 Ware St.
   Cambridge, MA 02138

   Phone: +1 617 495 3864
   EMail: sob@harvard.edu


   Allison Mankin
   USC/Information Sciences Institute
   4350 North Fairfax Drive, Suite 400
   Arlington, VA 22303

   Phone: +1 703-807-0132
   EMail: mankin@isi.edu

































Bradner & Mankin                                               [Page 43]

RFC 1752                Recommendation for IPng             January 1995


Appendix A - Summary of Recommendations

   5.3 Address Assignment Policy Recommendations
      changes in address assignment policies are not recommended
      reclamation of underutilized assigned addresses is not currently
         recommended
      efforts to renumber significant portions of the Internet are not
         currently recommended
      recommend consideration of assigning CIDR-type address blocks out
         of unassigned Class A addressees
   11. IPng Recommendation
      recommend that "Simple Internet Protocol Plus (SIPP) Spec. (128
         bit ver)" [Deering94b] be adopted as the basis for IPng
      recommend that the documents listed in Appendix C be the basis of
         IPng
   13. IPng Working Group
      recommend that an IPng Working Group be formed, chaired by Steve
         Deering and Ross Callon
      recommend that Robert Hinden be the document editor for the IPng
         effort
   14. IPng Reviewer
      recommend that an IPng Reviewer be appointed and that Dave Clark
         be that reviewer
   15. Address Autoconfiguration
      recommend that an Address Autoconfiguration Working Group be
         formed, chaired by Dave Katz and Sue Thomson
   16.1 Transition - Short Term
      recommend that an IPng Transition Working Group be formed, chaired
         by Bob Gilligan and TBA
   16.2 Transition - Long Term
      recommend that the Transition and Coexistence Including Testing
         Working Group be chartered
   17. Other Address Families
      recommend that recommendations about the use of non-IPv6 addresses
         in IPv6 environments and IPv6 addresses in non-IPv6
         environments be developed
   18. Impact on Other IETF Standards
      recommend the IESG commission a review of all standards track RFCs
      recommend the IESG charge current IETF working groups with the
         task of understanding the impact of IPng on their proposals
         and, where appropriate, revise the documents to include support
         for IPng
      recommend the IESG charter new working groups where required to
         revise other standards RFCs
   20. APIs
      recommend that Informational RFCs be developed or solicited for a
         few of the common APIs




Bradner & Mankin                                               [Page 44]

RFC 1752                Recommendation for IPng             January 1995


   21. Future of the IPng Area and Working Groups
      recommend that the IPng Area and Area Directorate continue until
         main documents are offered as Proposed Standards in late 1994
   22. Security Considerations
      recommend that support for the Authentication Header be required
      recommend that support for a specific authentication algorithm be
         required
      recommend that support for the Privacy Header be required
      recommend that support for a specific privacy algorithm be
         required
      recommend that an "IPng framework for firewalls" be developed

Appendix B - IPng Area Directorate

   J. Allard - Microsoft           <jallard@microsoft.com>
   Steve Bellovin  - AT&T          <smb@research.att.com>
   Jim Bound  - Digital            <bound@zk3.dec.com>
   Ross Callon  - Wellfleet        <rcallon@wellfleet.com>
   Brian Carpenter  - CERN         <brian.carpenter@cern.ch>
   Dave Clark  - MIT               <ddc@lcs.mit.edu >
   John Curran  - NEARNET          <curran@nic.near.net>
   Steve Deering  - Xerox          <deering@parc.xerox.com>
   Dino Farinacci  - Cisco         <dino@cisco.com>
   Paul Francis - NTT              <francis@slab.ntt.jp>
   Eric Fleischmann  - Boeing      <ericf@atc.boeing.com>
   Mark Knopper - Ameritech        <mak@aads.com>
   Greg Minshall  - Novell         <minshall@wc.novell.com>
   Rob Ullmann - Lotus             <ariel@world.std.com>
   Lixia Zhang  - Xerox            <lixia@parc.xerox.com>

   Daniel Karrenberg of RIPE joined the Directorate when it was formed
   but had to withdraw due to the demands of his day job.

   Since the Toronto IETF meeting Paul Francis has resigned from the
   Directorate to pursue other interests.  Robert Hinden of Sun
   Microsystems and Yakov Rekhter of IBM joined.















Bradner & Mankin                                               [Page 45]

RFC 1752                Recommendation for IPng             January 1995


Appendix C - Documents Referred to the IPng Working Groups

   [Deering94b] Deering, S., "Simple Internet Protocol Plus (SIPP) Spec.
      (128 bit ver)", Work in Progress.

   [Francis94] Francis, P., "SIPP Addressing Architecture", Work in
      Progress.

   [Rekhter94] Rekhter, Y., and T. Li, "An Architecture for IPv6 Unicast
      Address Allocation", Work in Progress.

   [Gillig94a] Gilligan, R., "Simple SIPP Transition (SST) Overview",
      Work in Progress.

   [Gillig94b] Gilligan, R., Govindan, R., Thomson, S., and J. Bound,
      "SIPP Program Interfaces for BSD Systems", Work in Progress.

   [Atkins94a] Atkinson, R., "SIPP Security Architecture", Work in
      Progress.

   [Atkins94b] Atkinson, R., "SIPP Authentication Header", Work in
      Progress.

   [Ford94b] Ford, P., Li, T., and Y. Rekhter, "SDRP Routing Header for
      SIPP-16", Work in Progress.

   [Hinden94c] Hinden, R., "IP Next Generation Overview", Work in
      Progress.

Appendix D - IPng Proposal Overviews

   [Ford94a] Ford, P., and M. Knopper, "TUBA as IPng: A White Paper",
      Work in Progress.

   [Hinden94a] Hinden, R., "Simple Internet Protocol Plus White Paper",
      RFC 1710, Sun Microsystems, October 1994.

   [McGovern94] McGovern, M., and R. Ullmann, "CATNIP: Common
      Architecture for the Internet", RFC 1707, Sunspot Graphics, Lotus
      Development Corp., October 1994.











Bradner & Mankin                                               [Page 46]

RFC 1752                Recommendation for IPng             January 1995


Appendix E - RFC 1550 White Papers

   [Adam94] Adamson, B., "Tactical Radio Frequency Communication
      Requirements for IPng", RFC 1677, NRL, August 1994.

   [Bello94a] Bellovin, S., "On Many Addresses per Host", RFC 1681, AT&T
      Bell Laboratories, August 1994.

   [Bello94b] Bellovin, S., "Security Concerns for IPng", RFC 1675, AT&T
      Bell Laboratories, August 1994.

   [Bound94] Bound, J., "IPng BSD Host Implementation Analysis", RFC
      1682, Digital Equipment Corporation, August 1994.

   [Brazd94] Brazdziunas, C., "IPng Support for ATM Services", RFC 1680,
      Bellcore, August 1994.

   [Britt94] Britton, E., and J. Tavs, "IPng Requirements of Large
      Corporate Networks", RFC 1678, IBM, August 1994.

   [Brownl94] Brownlee, J., "Accounting Requirements for IPng", RFC
      1672, University of Auckland, August 1994.

   [Carpen94a] Carpenter, B., "IPng White Paper on Transition and Other
      Considerations", RFC 1671, CERN, August 1994.

   [Chiappa94] Chiappa, N., "IPng Technical Requirements Of the Nimrod
      Routing and Addressing Architecture", RFC 1753, December 1994.

   [Clark94] Clark, R., Ammar, M., and K. Calvert, "Multiprotocol
      Interoperability In IPng", RFC 1683, Georgia Institute of
      Technology, August 1994.

   [Curran94] Curran, J., "Market Viability as a IPng Criteria", RFC
      1669, BBN, August 1994.

   [Estrin94a] Estrin, D., Li, T., and Y. Rekhter, "Unified Routing
      Requirements for IPng", RFC 1668, USC, cisco Systems, IBM, August
      1994.

   [Fleisch94] Fleischman, E., "A Large Corporate User's View of IPng",
      RFC 1687, Boeing Computer Services, August 1994.

   [Green94] 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.





Bradner & Mankin                                               [Page 47]

RFC 1752                Recommendation for IPng             January 1995


   [Ghisel94] Ghiselli, A., Salomoni, D., and C. Vistoli, "INFN
      Requirements for an IPng", RFC 1676, INFN/CNAF, August 1994.

   [Heager94] Heagerty, D., "Input to IPng Engineering Considerations",
      RFC 1670, CERN, August 1994.

   [Simpson94] Simpson, W. "IPng Mobility Considerations", RFC 1688,
      Daydreamer, August 1994.

   [Skelton94] Skelton, R., "Electric Power Research Institute Comments
      on IPng", RFC 1673, EPRI, August 1994.

   [Syming94] Symington, S., Wood, D., and J. Pullen, "Modeling and
      Simulation Requirements for IPng", RFC 1667, MITRE, George Mason
      University, August 1994.

   [Taylor94] Taylor, M., "A Cellular Industry View of IPng", RFC 1674,
      CDPD Consortium, August 1994.

   [Vecchi94] Vecchi, M., "IPng Requirements: A Cable Television
      Industry Viewpoint", RFC 1686, Time Warner Cable, August 1994.

Appendix F - Additional References

   [Almqu92] Almquist, P., "Minutes of the Selection Criteria BOF",
      Washington DC IETF, November 1992, (ietf/nov92/select-minutes-
      92nov.txt).

   [Berkow94] Berkowitz, H., "IPng and Related Plug-and-Play Issues and
      Requirements", Work in Progress, September 1994.

   [Bos94] Bos, E. J., "Minutes of the Address Lifetime Expectations BOF
      (ALE)", Seattle IETF, March 1994, (ietf/ale/ale-minutes-
      94mar.txt).

   [Big] Archives of the big-internet mailing list, on munnari.oz.au in
      big-internet/list-archives.

   [Bradner93] Bradner, S., and A. Mankin, "IP: Next Generation (IPng)
      White Paper Solicitation", RFC 1550, Harvard University, NRL,
      December 1993.

   [Callon87] Callon, R., "A Proposal for a Next Generation Internet
      Protocol", Proposal to X3S3, December 1987.

   [Callon92a] Callon, R., "CNAT", Work in Progress.

   [Callon92b] Callon, R., "Simple CLNP", Work in Progress.



Bradner & Mankin                                               [Page 48]

RFC 1752                Recommendation for IPng             January 1995


   [Callon92c] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A
      Simple Proposal for Internet Addressing and Routing", RFC 1347,
      DEC, June 1992.

   [Carpen93] Carpenter, B. and T. Dixon, "Minutes of the IPng Decision
      Process BOF (IPDECIDE)", /ietf/93jul/ipdecide-minutes-93jul.txt,
      August 1993.

   [Carpen94b] Carpenter, B, and J. Bound, "Recommendations for OSI NSAP
      usage in IPv6", Work in Progress.

   [Chiappa91]  Chiappa, J., "A New IP Routing and Addressing
      Architecture", Work in Progress.

   [Clark91] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
      "Towards the Future Internet Architecture", RFC 1287, MIT, BBN,
      CNRI, ISI, UC Davis, December 1991.

   [Deering92] Deering, S., "The Simple Internet Protocol", Big-Internet
      mailing list, 22 Sept. 1992.

   [Deering94a] Deering, S., and P. Francis, Message to sipp mailing
      list, 31 May 1994.

   [Estrin94b] Estrin, D., Zappala, D., Li, T., Rekhter, Y., and K.
      Varadhan, "Source Demand Routing: Packet Format and Forwarding
      Specification (Version 1)" Work in Progress.

   [Fuller93] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
      Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
      Strategy", RFC 1519, BARRNet, cisco Systems, MERIT, OARnet,
      September 1993.

   [Gillig94c] Gilligan, B., "IPng Transition (ngtrans)", Work in
      Progress.

   [Gross92} Gross, P., and P. Almquist, "IESG Deliberations on Routing
      and Addressing", RFC 1380, ANS, Stanford University, November
      1992.

   [Gross94] Gross, P. "A Direction for IPng", RFC 1719, MCI, December
      1994.

   [Hinden92a] Hinden, R., "New Scheme for Internet Routing and
      Addressing (ENCAPS)", Work in Progress.

   [Hinden94b] Hinden, R., Deering, S., and P. Francis, "Simple Internet
      Protocol Plus", Working Group Charter, April 1994.



Bradner & Mankin                                               [Page 49]

RFC 1752                Recommendation for IPng             January 1995


   [Hinden92b] Hinden, R., and D. Crocker, "A Proposal for IP Address
      Encapsulation (IPAE): A Compatible version of IP with Large
      Addresses", Work in Progress.

   [Huston94] Huston, G., and A. Bansal, draft charter for the
      "Transition and Coexistence Including Testing (TACIT) Working
      Group, June 1994.

   [Huitema93] Huitema, C., "IAB Recommendations for an Intermediate
      Strategy to Address the Issue of Scaling", RFC 1481, INRIA, July
      1993.

   [Huitema94] Huitema, C., "The H ratio for address assignment
      efficiency", RFC 1715, INRIA, October 1994.

   [IAB92] Internet Architecture Board, "IP Version 7", Work in
      Progress.

   [IAB94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
      of IAB Workshop on Security in the Internet Architecture -
      February 8-10, 1994", RFC 1636, USC/Informaiton Sciences
      Institute, MIT Laboratory for Computer Science, Trusted
      Information Systems, Inc., INRIA, IAB Chair, June 1994.

   [Kasten92] Kastenholz, F, and C. Partridge, "IPv7 Technical
      Criteria", Work in Progress.

   [Kasten94] Partridge, C., and F. Kastenholz, "Technical Criteria for
      Choosing IP: The Next Generation (IPng)", RFC 1726, BBN Systems
      and Technologies, FTP Software, December 1994.

   [Knopper94a] Knopper, M., and P. Ford, "TCP/UDP Over CLNP-Addressed
      Networks (TUBA)", Working Group Charter, January 1994.

   [Knopper94b] Knopper, M., and D. Piscitello, "Minutes of the BigTen
      IPng Retreat, May 19 & 20 1994".

   [Leiner93] Leiner, B., and Y. Rekhter, "The MultiProtocol Internet",
      RFC 1560, USRA, IBM, December 1993.

   [Mankin94] Mankin, A., and S. Bradner, message to big-internet, tuba,
      sipp, catnip and ietf mailing lists, 7 July 1994.

   [Mills84] Mills, D. "Exterior Gateway Protocol Formal Specification",
      RFC 904, UDEL, April 1984.

   [Mogul90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
      DECWRL, Stanford University, November 1990.



Bradner & Mankin                                               [Page 50]

RFC 1752                Recommendation for IPng             January 1995


   [Nat94] National Research Council, "Realizing the Information Future:
      The Internet and Beyond", National Academy Press, 1994.

   [Piscit94] Piscitello, D., "FTP Operation Over Big Address Records
      (FOOBAR)", RFC 1639, Core Competence, June 1994.

   [Provan91] Provan, D., "Transmitting IP Traffic over ARCNET
      Networks", RFC 1051, Novell, February 1991.

   [Postel94] Postel, J., Editor, "Internet Official Protocol
      Standards", RFC 1720, USC/Information Sciences Institute, November
      1994.

   [Solens93a] Solensky, F., and T. Li, "Charter for the Address
      Lifetime Expectations Working Group", FTP Software, Cisco Systems,
      November 1993.

   [Solens93b] Solensky, F., "Minutes of the Address Lifetime
      Expectations BOF (ALE)", Houston IETF, November 1993,
      (ietf/ale/ale-minutes-93nov.txt).

   [Solens94] Solensky, F., "Minutes of the Address Lifetime
      Expectations BOF (ALE)", Toronto IETF, July 1994, (ietf/ale/ale-
      minutes-94jul.txt).

   [Sukonnik94] Sukonnik, V., "Common Architecture for Next-Generation
      IP (catnip), Working Group Charter, April 1994.

   [Tsuchiya92] Tsuchiya, P., "The 'P' Internet Protocol", Work in
      Progress.

   [Ullmann93] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
      Process Software Corporation, June 1993.


















Bradner & Mankin                                               [Page 51]

RFC 1752                Recommendation for IPng             January 1995


Appendix G - Acknowledgments

   Reaching this stage of the recommendation would not have been even
   vaguely possible without the efforts of many people.  In particular,
   the work of IPng Directorate (listed in Appendix B), Frank Kastenholz
   and Craig Partridge (the authors of the Criteria document) along with
   Jon Crowcroft (who co-chaired the ngreq BOF) was critical.  The work
   and cooperation of the chairs, members and document authors of the
   three IPng proposal working groups, the ALE working group and the
   TACIT working group laid the groundwork upon which this
   recommendation sits.

   We would also like to thank the many people who took the time to
   respond to RFC1550 and who provided the broad understanding of the
   many requirements of data networking that any proposal for an IPng
   must address.

   The members of the IESG, the IAB, and the always active participants
   in the various mailing lists provided us with many insights into the
   issues we faced.

   Many other individuals gave us sometimes spirited but always useful
   counsel during this process.  They include (in no particular order)
   Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave
   Piscitello, Vint Cerf and Dan Lynch.

   Thanks to David Williams and Cheryl Chapman who took on the
   occasionally impossible task of ensuring that what is written here
   resembles English to some degree.

   To all of the many people mentioned above and those we have skipped
   in our forgetfulness, thank you for making this task doable.



















Bradner & Mankin                                               [Page 52]