File: rfc1621.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2859 lines) | stat: -rw-r--r-- 128,905 bytes parent folder | download | duplicates (5)
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






Network Working Group                                         P. Francis
Request for Comments: 1621                                           NTT
Category: Informational                                         May 1994


                       Pip Near-term Architecture

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Preamble

   During 1992 and 1993, the Pip internet protocol, developed at
   Belclore, was one of the candidate replacments for IP.  In mid 1993,
   Pip was merged with another candidate, the Simple Internet Protocol
   (SIP), creating SIPP (SIP Plus).  While the major aspects of Pip--
   particularly its distinction of identifier from address, and its use
   of the source route mechanism to achieve rich routing capabilities--
   were preserved, many of the ideas in Pip were not.  The purpose of
   this RFC and the companion RFC "Pip Header Processing" are to record
   the ideas (good and bad) of Pip.

   This document references a number of Pip draft memos that were in
   various stages of completion.  The basic ideas of those memos are
   presented in this document, though many details are lost.  The very
   interested reader can obtain those internet drafts by requesting them
   directly from me at <francis@cactus.ntt.jp>.

   The remainder of this document is taken verbatim from the Pip draft
   memo of the same title that existed when the Pip project ended.  As
   such, any text that indicates that Pip is an intended replacement for
   IP should be ignored.

Abstract

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   evolve to all forseeable internet protocol requirements.  This
   specification describes the routing and addressing architecture for
   near-term Pip deployment.  We say near-term only because Pip is
   designed with evolution in mind, so other architectures are expected
   in the future.  This document, however, makes no reference to such
   future architectures.





Francis                                                         [Page 1]

RFC 1621               Pip Near-term Architecture               May 1994


Table of Contents

   1. Pip Architecture Overview ...................................    4
   1.1 Pip Architecture Characteristics ...........................    4
   1.2 Components of the Pip Architecture .........................    5

   2. A Simple Example ............................................    6

   3. Pip Overview ................................................    7

   4. Pip Addressing ..............................................    9
   4.1 Hierarchical Pip Addressing ................................    9
   4.1.1 Assignment of (Hierarchical) Pip Addresses ...............   12
   4.1.2 Host Addressing ..........................................   14
   4.2 CBT Style Multicast Addresses ..............................   15
   4.3 Class D Style Multicast Addresses ..........................   16
   4.4 Anycast Addressing .........................................   16

   5. Pip IDs .....................................................   17

   6. Use of DNS ..................................................   18
   6.1 Information Held by DNS ....................................   19
   6.2 Authoritative Queries in DNS ...............................   20

   7. Type-of-Service (TOS) (or lack thereof) .....................   21

   8. Routing on (Hierarchical) Pip Addresses .....................   22
   8.1 Exiting a Private Domain ...................................   23
   8.2 Intra-domain Networking ....................................   24

   9. Pip Header Server ...........................................   25
   9.1 Forming Pip Headers ........................................   25
   9.2 Pip Header Protocol (PHP) ..................................   27
   9.3 Application Interface ......................................   27

   10. Routing Algorithms in Pip ..................................   28
   10.1 Routing Information Filtering .............................   29

   11. Transition .................................................   30
   11.1 Justification for Pip Transition Scheme ...................   31
   11.2 Architecture for Pip Transition Scheme ....................   31
   11.3 Translation between Pip and IP packets ....................   33
   11.4 Translating between PCMP and ICMP .........................   34
   11.5 Translating between IP and Pip Routing Information ........   34
   11.6 Old TCP and Application Binaries in Pip Hosts .............   34
   11.7 Translating between Pip Capable and non-Pip Capable DNS
        Servers ...................................................   35




Francis                                                         [Page 2]

RFC 1621               Pip Near-term Architecture               May 1994


   12. Pip Address and ID Auto-configuration ......................   37
   12.1 Pip Address Prefix Administration .........................   37
   12.2 Host Autoconfiguration ....................................   38
   12.2.1 Host Initial Pip ID Creation ............................   38
   12.2.2 Host Pip Address Assignment .............................   39
   12.2.3 Pip ID and Domain Name Assignment .......................   39

   13. Pip Control Message Protocol (PCMP) ........................   40

   14. Host Mobility ..............................................   42
   14.1 PCMP Mobile Host message ..................................   43
   14.2 Spoofing Pip IDs ..........................................   44

   15. Public Data Network (PDN) Address Discovery ................   44
   15.1 Notes on Carrying PDN Addresses in NSAPs ..................   46

   16. Evolution with Pip .........................................   46
   16.1 Handling Directive (HD) and Routing Context (RC) Evolution.   49
   16.1.1 Options Evolution .......................................   50
   References .....................................................   51
   Security Considerations ........................................   51
   Author's Address ...............................................   51





























Francis                                                         [Page 3]

RFC 1621               Pip Near-term Architecture               May 1994


Introduction

   Pip is an internet protocol intended as the replacement for IP
   version 4.  Pip is a general purpose internet protocol, designed to
   handle all forseeable internet protocol requirements.  This
   specification describes the routing and addressing architecture for
   near-term Pip deployment.  We say near-term only because Pip is
   designed with evolution in mind, so other architectures are expected
   in the future.  This document, however, makes no reference to such
   future architectures (except in that it discusses Pip evolution in
   general).

   This document gives an overall picture of how Pip operates.  It is
   provided primarily as a framework within which to understand the
   total set of documents that comprise Pip.

1.  Pip Architecture Overview

   The Pip near-term architecture is an incremental step from IP.  Like
   IP, near-term Pip is datagram.  Pip runs under TCP and UDP.  DNS is
   used in the same fashion it is now used to distribute name to Pip
   Address (and ID) mappings.  Routing in the near-term Pip architecture
   is hop-by-hop, though it is possible for a host to create a domain-
   level source route (for policy reasons).

   Pip Addresses have more hierarchy than IP, thus improving scaling on
   one hand, but introducing additional addressing complexities, such as
   multiple addresses, on the other.  Pip, however, uses hierarchical
   addresses to advantage by making them provider-based, and using them
   to make policy routing (in this case, provider selection) choices.
   Pip also provides mechanisms for automatically assigning provider
   prefixes to hosts and routers in domains.  This is the main
   difference between the Pip near-term architecture and the IP
   architecture.  (Note that in the remainder of this paper, unless
   otherwise stated, the phrase "Pip architecture" refers to the near-
   term Pip architecture described herein.)

2.  Pip Architecture Characteristics

   The proposed architecture for near-term Pip has the following
   characteristics:

   1.  Provider-rooted hierarchical addresses.

   2.  Automatic domain-wide address prefix assignment.

   3.  Automatic host address and ID assignment.




Francis                                                         [Page 4]

RFC 1621               Pip Near-term Architecture               May 1994


   4.  Exit provider selection.

   5.  Multiple defaults routing (default routing, but to multiple exit
       points).

   6.  Equivalent of IP Class D style addressing for multicast.

   7.  CBT style multicast.

   8.  "Anycast" addressing (route to one of a group, usually the
       nearest).

   9.  Providers support forwarding on policy routes (but initially will
       not provide the support for sources to calculate policy routes).

   10.  Mobile hosts.

   11.  Support for routing across large Public Data Networks (PDN).

   12.  Inter-operation with IP hosts (but, only within an IP-address
        domain where IP addresses are unique).  In particular, an IP
        address can be explicitly carried in a Pip header.

   13.  Operation with existing transport and application binaries
        (though if the application contains IP context, like FTP, it may
        only work within a domain where IP addresses are unique).

   14.  Mechanisms for evolving Pip beyond the near-term architecture.

1.2 Components of the Pip Architecture

   The Pip Architecture consists of the following five systems:

   1.  Host (source and sink of Pip packets)

   2.  Router (forwards Pip packets)

   3.  DNS

   4.  Pip/IP Translator

   5.  Pip Header Server (formats Pip headers)

   The first three systems exist in the IP architecture, and require no
   explanation here.  The fourth system, the Pip/IP Translator, is
   required solely for the purpose of inter-operating with current IP
   systems.  All Pip routers are also Pip/IP translators.




Francis                                                         [Page 5]

RFC 1621               Pip Near-term Architecture               May 1994


   The fifth system, the Pip Header Server, is new.  Its function is to
   format Pip headers on behalf of the source host (though initially
   hosts will be able to do this themselves).  This use of the Pip
   Header Server will increase as policy routing becomes more
   sophisticated (moves beyond near-term Pip Architecture capabilities).

   To handle future evolution, a Pip Header Server can be used to
   "spoon-feed" Pip headers to old hosts that have not been updated to
   understand new uses of Pip.  This way, the probability that the
   internet can evolve without changing all hosts is increased.

2.  A Simple Example

   A typical Pip "exchange" is as follows: An application initiates an
   exchange with another host as identified by a domain name.  A request
   for one or more Pip Headers, containing the domain name of the
   destination host, goes to the Pip Header Server.  The Pip Header
   Server generates a DNS request, and receive back a Pip ID, multiple
   Pip Addresses, and possibly other information such as a mobile host
   server or a PDN address.  Given this information, plus information
   about the source host (its Pip Addresses, for instance), plus
   optionally policy information, plus optionally topology information,
   the Pip Header Server formats an ordered list of valid Pip headers
   and give these to the host.  (Note that if the Pip Header Server is
   co-resident with the host, as will be common initially, the host
   behavior is similar to that of an IP host in that a DNS request comes
   from the host, and the host forms a Pip header based on the answer
   from DNS.)

   The source host then begins to transmit Pip packets to the
   destination host.  If the destination host is an IP host, then the
   Pip packet is translated into an IP packet along the way.  Assuming
   that the destination host is a Pip host, however, the destination
   host uses the destination Pip ID alone to determine if the packet is
   destined for it.  The destination host generates a return Pip header
   based either on information in the received Pip header, or the
   destination host uses the Pip ID of the source host to query the Pip
   Header Server/DNS itself.  The latter case involves more overhead,
   but allows a more informed decision about how to return packets to
   the originating host.

   If either host is mobile, and moves to a new location, thus getting a
   new Pip Address, it informs the other host of its new address
   directly.  Since host identification is based on the Pip ID and not
   the Pip Address, this doesn't cause transport level to fail.  If both
   hosts are mobile and receive new Pip Addresses at the same time (and
   thus cannot exchange packets at all), then they can query each
   other's respective mobile host servers (learned from DNS).  Note that



Francis                                                         [Page 6]

RFC 1621               Pip Near-term Architecture               May 1994


   keeping track of host mobility is completely confined to hosts.
   Routers never get involved in tracking mobile hosts (though naturally
   they are involved in host discovery and automatic host address
   assignment).

3.  Pip Overview

   Here, a brief overview of the Pip protocol is given.  The reader is
   encouraged to read [2] for a complete description.

   The Pip header is divided into three parts:

      Initial Part
      Transit Part
      Options Part

   The Initial Part contains the following fields:

      Version Number
      Options Offset, OP Contents, Options Present (OP)
      Packet SubID
      Protocol
      Dest ID
      Source ID
      Payload Length
      Host Version
      Payload Offset
      Hop Count

   All of the fields in the Initial Part are of fixed length.  The
   Initial Part is 8 32-bit words in length.

   The Version Number places Pip as a subsequent version of IP.  The
   Options Offset, OP Contents, and Options Present (OP) fields tell how
   to process the options.  The Options Offset tells where the options
   are The OP tells which of up to 8 options are in the options part, so
   that the Pip system can efficiently ignore options that don't pertain
   to it.  The OP Contents is like a version number for the OP field.
   It allows for different sets of the (up to 8) options.

   The Packet SubID is used to relate a received PCMP message to a
   previously sent Pip packet.  This is necessary because, since routers
   in Pip can tag packets, the packet returned to a host in a PCMP
   message may not be the same as the packet sent.  The Payload Length
   and Protocol take the place of IP's Total Length and Protocol fields
   respectively.  The Dest ID identifies the destination host, and is
   not used for routing, except for where the final router on a LAN uses
   ARP to find the physical address of the host identified by the dest



Francis                                                         [Page 7]

RFC 1621               Pip Near-term Architecture               May 1994


   ID.  The Source ID identifies the source of the packet.  The Host
   Version tells what control algorithms the host has implemented, so
   that routers can respond to hosts appropriately.  This is an
   evolution mechanism.  The Hop Count is similar to IP's Time-to-Live.

   The Transit Part contains the following fields:

      Transit Part Offset
      HD Contents
      Handling Directive (HD)
      Active FTIF
      RC Contents
      Routing Context (RC)
      FTIF Chain (FTIF = Forwarding Table Index Field)

   Except for the FTIF Chain, which can have a variable number of 16-bit
   FTIF fields, the fields in the Transit Part are of fixed length, and
   are three 32-bit words in length.

   The Transit Part Offset gives the length of the Transit Part.  This
   is used to determine the location of the subsequent Transit Part (in
   the case of Transit Part encapsulation).

   The Handling Directive (HD) is a set of subfields, each of which
   indicates a specific handling action that must be executed on the
   packet.  Handling directives have no influence on routing.  The HD
   Contents field indicates what subfields are in the Handling
   Directive.  This allows the definition of the set of handling
   directives to evolve over time.  Example handling directives are
   queueing priority, congestion experienced bit, drop priority, and so
   on.

   The remaining fields comprise the Routing Directive.  This is where
   the routing decision gets made.  The basic algorithm is that the
   router uses the Routing Context to choose one of multiple forwarding
   tables.  The Active FTIF indicates which of the FTIFs to retrieve,
   which is then used as an index into the forwarding table, which
   either instructs the router to look at the next FTIF, or returns the
   forwarding information.

   Examples of Routing Context uses are; to distinguish address families
   (multicast vs. unicast), to indicate which level of the hierarchy a
   packet is being routed at, and to indicate a Type of Service.  In the
   near-term architecture, the FTIF Chain is used to carry source and
   destination hierarchical unicast addresses, policy route fragments,
   multicast addresses (all-of-group), and anycast (one-of-group)
   addresses.  Like the OP Contents and HD Contents fields, the RC
   Contents field indicates what subfields are in the Routing Context.



Francis                                                         [Page 8]

RFC 1621               Pip Near-term Architecture               May 1994


   This allows the definition of the Routing Context to evolve over
   time.

   The Options Part contains the options.  The options are preceded by
   an array of 8 fields that gives the offset of each of up to 8
   options.  Thus, a particular option can be found without a serial
   search of the list of options.

4.  Pip Addressing

   Addressing is the core of any internet architecture.  Pip Addresses
   are carried in the Routing Directive (RD) of the Pip header (except
   for the Pip ID, which in certain circumstances functions as part of
   the Pip Address).  Pip Addresses are used only for routing packets.
   They do not identify the source and destination of a Pip packet.  The
   Pip ID does this.  Here we describe and justify the Pip Addressing
   types.

   There are four Pip Address types [11].  The hierarchical Pip Address
   (referred to simply as the Pip Address) is used for scalable unicast
   and for the unicast part of a CBT-style multicast and anycast.  The
   multicast part of a CBT-style multicast is the second Pip address
   type.  The third Pip address type is class-D style multicast.  The
   fourth type of Pip address is the so-called "anycast" address.  This
   address causes the packet to be forwarded to one of a class of
   destinations (such as, to the nearest DNS server).

   Bits 0 and 1 of the RC defined by RC Contents value of 1 (that is,
   for the near-term Pip architecture) indicate which of four address
   families the FTIFs and Dest ID apply to.  The values are:

      Value      Address Family
      -----      --------------
       00        Hierarchical Unicast Pip Address
       01        Class D Style Multicast Address
       10        CBT Style Multicast Address
       11        Anycast Pip Address

   The remaining bits are defined differently for different address
   families, and are defined in the following sections.

4.1  Hierarchical Pip Addressing

   The primary purpose of a hierarchical address is to allow better
   scaling of routing information, though Pip also uses the "path"
   information latent in hierarchical addresses for making provider
   selection (policy routing) decisions.




Francis                                                         [Page 9]

RFC 1621               Pip Near-term Architecture               May 1994


   The Pip Header encodes addresses as a series of separate numbers, one
   number for each level of hierarchy.  This can be contrasted to
   traditional packet encodings of addresses, which places the entire
   address into one field.  Because of Pip's encoding, it is not
   necessary to specify a format for a Pip Address as it is with
   traditional addresses (for instance, the SIP address is formatted
   such that the first so-many bits are the country/metro code, the next
   so-many bits are the site/subscriber, and so on).  Pip's encoding
   also eliminates the "cornering in" effect of running out of space in
   one part of the hierarchy even though there is plenty of room in
   another.  No "field sizing" decisions need be made at all with Pip
   Addresses.  This makes address assignment easier and more flexible
   than with traditional addresses.

   Pip Addresses are carried in DNS as a series of numbers, usually with
   each number representing a layer of the hierarchy [1], but optionally
   with the initial number(s) representing a "route fragment" (the tail
   end of a policy route--a source route whose elements are providers).
   The route fragments would be used, for instance, when the destination
   network's directly attached (local access) provider is only giving
   access to other (long distance) providers, but the important
   provider-selection policy decision has to do the long distance
   providers.

   The RC for (hierarchical) Pip Addresses is defined as:

      bits       meaning
      ----       -------
      0,1        Pip Address (= 00)
      2,3        level
      4,5        metalevel
      6          exit routing type

   The level and metalevel subfields are used to indicate what level of
   the hierarchy the packet is currently at (see section 8).  The exit
   routing type subfield is used to indicate whether host-driven (hosts
   decide exit provider) or router-driven (routers decide exit provider)
   exit routing is in effect (see section 8.1).

   Each FTIF in the FTIF Chain is 16 bits in length.  The low-order part
   of each FTIF in a (hierarchical unicast) Pip Address indicates the
   relationship of the FTIF with the next FTIF.  The three relators are
   Vertical, Horizontal, and Extension.  The Vertical and Horizontal
   relators indicate if the subsequent FTIF is hierarchically above or
   below (Vertical) or hierarchically unrelated (Horizontal).  The
   Extension relator is used to encode FTIF values longer than 16 bits.





Francis                                                        [Page 10]

RFC 1621               Pip Near-term Architecture               May 1994


   FTIF values 0 - 31 are reserved for special purposes.  That is, they
   cannot be assigned to normal hierarchical elements.  FTIF value 1 is
   defined as a flag to indicate a switch from the unicast phase of
   packet forwarding to the anycast phase of packet forwarding.

   Note that Pip Addresses do not need to be seen by protocol layers
   above Pip (though layers above Pip can provide a Pip Address if
   desired).  Transport and above use the Pip ID to identify the source
   and destination of a Pip packet.  The Pip layer is able to map the
   Pip IDs (and other information received from the layer above, such as
   QOS) into Pip Addresses.

   The Pip ID can serve as the lowest level of a Pip Address.  While
   this "bends the principal" of separating Pip Addressing from Pip
   Identification, it greatly simplifies dynamic host address
   assignment.  The Pip ID also serves as a multicast ID.  Unless
   otherwise stated, the term "Pip Address" refers to just the part in
   the Routing Directive (that is, excludes the Pip ID).

   Pip Addresses are provider-rooted (as opposed to geographical).  That
   is, the top-level of a Pip Address indicates a network service
   provider (even when the service provided is not Pip).  (A
   justification of using provider-rooted rather than geographical
   addresses is given in [12].)

   Thus, the basic form of a Pip address is:

         providerPart,subscriberPart

   where both the providerPart and subscriberPart can have multiple
   layers of hierarchy internally.

   A subscriber may be attached to multiple providers.  In this case, a
   host can end up with multiple Pip Addresses by virtue of having
   multiple providerParts:

         providerPart1,subscriberPart
         providerPart2,subscriberPart
         providerPart3,subscriberPart

   This applies to the case where the subscriber network spans many
   different provider areas, for instance, a global corporate network.
   In this case, some hosts in the global corporate network will have
   certain providerParts, and other hosts will have others.  The
   subscriberPart should be assigned such that routing can successfully
   take place without a providerPart in the destination Pip Address of
   the Pip Routing Directive (see section 8.2).




Francis                                                        [Page 11]

RFC 1621               Pip Near-term Architecture               May 1994


   Note that, while there are three providerParts shown, there is only
   one subscriberPart.  Internal subscriber numbering should be
   independent of the providerPart.  Indeed, with the Pip architecture,
   it is possible to address internal packets without including any of
   the providerPart of the address.

   Top-level Pip numbers can be assigned to subscriber networks as well
   as to providers.

         privatePart,subscriberPart

   In this case, however, the top-level number (privatePart) would not
   be advertised globally.  The purpose of such an assignment is to give
   a private network "ownership" of a globally unique Pip Address space.
   Note that the privatePart is assigned as an extended FTIF (that is,
   from numbers greater than 2^15).  Because the privatePart is not
   advertised globally, and because internal packets do not need the
   prefix (above the subscriberPart), the privatePart actually never
   appears in a Pip packet header.

   Pip Addresses can be prepended with a route fragment.  That is, one
   or more Pip numbers that are all at the top of the hierarchy.

         longDistanceProvider.localAccessProvider.subscriber
             (top-level)          (top-level)     (next level)

   This is useful, for instance, when the subscriber's directly attached
   provider is a "local access" provider, and is not advertised
   globally.  In this case, the "long distance" provider is prepended to
   the address even though the local access provider number is enough to
   provide global uniqueness.

   Note that no coordination is required between the long distance and
   local access providers to form this address.  The subscriber with a
   prefix assigned to it by the local access provider can autonomously
   form and use this address.  It is only necessary that the long
   distance provider know how to route to the local access provider.

4.1.1  Assignment of (Hierarchical) Pip Addresses

   Administratively, Pip Addresses are assigned as follows [3].  There
   is a root Pip Address assignment authority.  Likely choices for this
   are IANA or ISOC.  The root authority assigns top-level Pip Address
   numbers.  (A "Pip Address number" is the number at a single level of
   the Pip Address hierarchy.  A Pip Address prefix is a series of
   contiguous Pip Address numbers, starting at the top level but not
   including the entire Pip Address.  Thus, the top-level prefix is the
   same thing as the top-level number.)



Francis                                                        [Page 12]

RFC 1621               Pip Near-term Architecture               May 1994


   Though by-and-large, and most importantly, top-level assignments are
   made to providers, each country is given an assignment, each existing
   address space (such as E.164, X.121, IP, etc.) is given an
   assignment, and private networks can be given assignments.  Thus,
   existing addresses can be grandfathered in.  Even if the top-level
   Pip address number is an administrative rather than topological
   assignment, the routing algorithm still advertises providers at the
   top (provider) level of routing.  That is, routing will advertise
   enough levels of hierarchy that providers know how to route to each
   other.

   There must be some means of validating top-level number requests from
   providers (basically, those numbers less than 2^15).  That is, top-
   level assignments must be made only to true providers.  While
   designing the best way to do this is outside the scope of this
   document, it seems off hand that a reasonable approach is to charge
   for the top-level prefixes.  The charge should be enough to
   discourage non-serious requests for prefixes, but not so much that it
   becomes an inhibitor to entry in the market.  The charge might
   include a yearly "rent", and top-level prefixes could be reclaimed
   when they are no longer used by the provider.  Any profit made from
   this activity could be used to support the overall role of number
   assignment.  Since roughly 32,000 top-level assignments can be made
   before having to increase the FTIF size in the Pip header from 16
   bits to 32 bits, it is envisioned that top-level prefixes will not be
   viewed as a scarce resource.

   After a provider obtains a top-level prefix, it becomes an assignment
   authority with respect to that particular prefix.  The provider has
   complete control over assignments at the next level down (the level
   below the top-level).  The provider may either assign top-level minus
   one prefixes to subscribers, or preferably use that level to provide
   hierarchy within the provider's network (for instance, in the case
   where the provider has so many subscribers that keeping routing
   information on all of them creates a scaling problem).  It is
   envisioned that the subscriber will have complete control over number
   assignments made at levels below that of the prefix assigned it by
   the provider.

   Assigning top level prefixes directly to providers leaves the number
   of top-level assignments open-ended, resulting in the possibility of
   scaling problems at the top level.  While it is expected that the
   number of providers will remain relatively small (say less than 10000
   globally), this can't be guaranteed.  If there are more providers
   than top-level routing can handle, it is likely that many of these
   providers will be "local access" providers--providers whose role is
   to give a subscriber access to multiple "long-distance" providers.
   In this case, the local access providers need not appear at the top



Francis                                                        [Page 13]

RFC 1621               Pip Near-term Architecture               May 1994


   level of routing, thus mitigating the scaling problem at that level.

   In the worst case, if there are too many top-level "long-distance"
   providers for top-level routing to handle, a layer of hierarchy above
   the top-level can be created.  This layer should probably conform to
   some policy criteria (as opposed to a geographical criteria).  For
   instance, backbones with similar access restrictions or type-of-
   service can be hierarchically clustered.  Clustering according to
   policy criteria rather than geographical allows the choice of address
   to remain an effective policy routing mechanism.  Of course, adding a
   layer of hierarchy to the top requires that all systems, over time,
   obtain a new providerPart prefix.  Since Pip has automatic prefix
   assignment, and since DNS hides addresses from users, this is not a
   debilitating problem.

4.1.2  Host Addressing

   Hosts can have multiple Pip Addresses.  Since Pip Addresses are
   topologically significant, a host has multiple Pip Addresses because
   it exists in multiple places topologically.  For instance, a host can
   have multiple Pip addresses because it can be reached via multiple
   providers, or because it has multiple physical interfaces.  The
   address used to reach the host influences the path to the host.

   Locally, Pip Addressing is similar to IP Addressing.  That is, Pip
   prefixes are assigned to subnetworks (where the term subnetwork here
   is meant in the OSI sense.  That is, it denotes a network operating
   at a lower layer than the Pip layer, for instance, a LAN).  Thus, it
   is not necessary to advertise individual hosts in routing updates--
   routers only need to advertise and store routes to subnetworks.

   Unlike IP, however, a single subnetwork can have multiple prefixes.
   (Strictly speaking, in IP a single subnetwork can have multiple
   prefixes, but a host may not be able to recognize that it can reach
   another host on the same subnetwork but with a different prefix
   without going through a router.)

   There are two styles of local Pip Addressing--one where the Pip
   Address denotes the host, and another where the Pip Address denotes
   only the destination subnetwork.  The latter style is called ID-
   tailed Pip Addressing.  With ID-tailed Pip Addresses, the Pip ID is
   used by the last router to forward the packet to the host.  It is
   expected that ID-tailed Pip Addressing is the most common, because it
   greatly eases address administration.

   (Note that the Pip Routing Directive can be used to route a Pip
   packet internal to a host.  For instance, the RD can be used to
   direct a packet to a device in a host, or even a certain memory



Francis                                                        [Page 14]

RFC 1621               Pip Near-term Architecture               May 1994


   location.  The use of the RD for this purpose is not part of this
   near-term Pip architecture.  We note, however, that this use of the
   RD could be locally done without effecting any other Pip systems.)

   When a router receives a Pip packet and determines that the packet is
   destined for a host on one of its' attached subnetworks (by examining
   the appropriate FTIF), it then examines the destination Pip ID (which
   is in a fixed position) and forwards based on that.  If it does not
   know the subnetwork address of the host, then it ARPs, using the Pip
   ID as the "address" in the ARP query.

4.2  CBT Style Multicast Addresses

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 10,
   the FTIF and Dest ID indicate CBT (Core Based Tree) style multicast.
   The remainder of the bits are defined as follows:


      bits       meaning
      ----       -------
      0,1        CBT Multicast (= 10)
      2,3        level
      4,5        metalevel
      6          exit routing type
      7          on-tree bit
      8,9        scoping


   With CBT (Core-based Tree) multicast, there is a single multicast
   tree connecting the members (recipients) of the multicast group (as
   opposed to Class-D style multicast, where there is a tree per
   source).  The tree emanates from a single "core" router.  To transmit
   to the group, a packet is routed to the core using unicast routing.
   Once the packet reaches a router on the tree, it is multicast using a
   group ID.

   Thus, the FTIF Chain for CBT multicast contains the (Unicast)
   Hierarchical Pip Address of the core router. The Dest ID field
   contains the group ID.

   A Pip CBT packet, then, has two phases of forwarding, a unicast phase
   and a multicast phase.  The "on-tree" bit of the RC indicates which
   phase the packet is in.  While in the unicast phase, the on-tree bit
   is set to 0, and the packet is forwarded similarly to Pip Addresses.
   During this phase, the scoping bits are ignored.






Francis                                                        [Page 15]

RFC 1621               Pip Near-term Architecture               May 1994


   Once the packet reaches the multicast tree, it switches to multicast
   routing by changing the on-tree bit to 1 and using the Dest ID group
   address for forwarding.  During this phase, bits 2-6 are ignored.

4.3  Class D Style Multicast Addresses

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 01,
   the FTIF and Dest ID indicate Class D style multicast.  The remainder
   of the RC is defined as:


      bits       meaning
      ----       -------
      0,1        Class D Style Multicast (= 01)
      2-5        Scoping


   By "class D" style multicast, we mean multicast using the algorithms
   developed for use with Class D addresses in IP (class D addresses are
   not used per se).  This style of routing uses both source and
   destination information to route the packet (source host address and
   destination multicast group).

   For Pip, the FTIF Chain holds the source Pip Address, in order of
   most significant hierarchy level first.  The reason for putting the
   source Pip Address rather than the Source ID in the FTIF Chain is
   that use of the source Pip Address allows the multicast routing to
   take advantage of the hierarchical source address, as is being done
   with IP.  The Dest ID field holds the multicast group.  The Routing
   Context indicates Class-D style multicast.  All routers must first
   look at the FTIF Chain and Dest ID field to route the packet on the
   tree.

   Bits 2 through 5 of the RC are the scoping bits.

4.4  Anycast Addressing

   When bits 1 and 0 of the RC defined by RC Contents = 1 are set to 11,
   the FTIF and Dest ID indicate Anycast addressing.  The remainder of
   the RC is defined as:











Francis                                                        [Page 16]

RFC 1621               Pip Near-term Architecture               May 1994


      bits       meaning
      ----       -------
      0,1        Anycast Address (= 11)
      2,3        level
      4,5        metalevel
      6          exit routing type
      7          anycast active
      8,9        scoping


   With anycast routing, the packet is unicast, but to the nearest of a
   group of destinations.  This type of routing is used by Pip for
   autoconfiguration.  Other applications, such as discovery protocols,
   may also use anycast routing.

   Like CBT, Pip anycast has two phases of operation, in this case the
   unicast phase and the anycast phase.  The unicast phase is for the
   purpose of getting the packet into a certain vicinity.  The anycast
   phase is to forward the packet to the nearest of a group of
   destinations in that vicinity.

   Thus, the RC has both unicast and anycast information in it.  During
   the unicast phase, the anycast active bit is set to 0, and the packet
   is forwarded according to the rules of Pip Addressing.  The scoping
   bits are ignored.

   The switch from the unicast phase to the anycast phase is triggered
   by the presence of an FTIF of value 1 in the FTIF Chain.  When this
   FTIF is reached, the anycast active bit is set to 1, the scoping bits
   take effect, and bits 2 through 6 are ignored.  When in the anycast
   phase, forwarding is based on the Dest ID field.

5.  Pip IDs

   The Pip ID is 64-bits in length [4].

   The basic role of the Pip ID is to identify the source and
   destination host of a Pip Packet.  (The other role of the Pip ID is
   for allowing a router to find the destination host on the destination
   subnetwork.)

   This having been said, it is possible for the Pip ID to ultimately
   identify something in addition to the host.  For instance, the Pip ID
   could identify a user or a process.  For this to work, however, the
   Pip ID has to be bound to the host, so that as far as the Pip layer
   is concerned, the ID is that of the host.  Any additional use of the
   Pip ID is outside the scope of this Pip architecture.




Francis                                                        [Page 17]

RFC 1621               Pip Near-term Architecture               May 1994


   The Pip ID is treated as flat.  When a host receives a Pip packet, it
   compares the destination Pip ID in the Pip header with its' own.  If
   there is a complete match, then the packet has reached the correct
   destination, and is sent to the higher layer protocol.  If there is
   not a complete match, then the packet is discarded, and a PCMP
   Invalid Address packet is returned to the originator of the packet
   [7].

   It is something of an open issue as to whether or not Pip IDs should
   contain significant organizational hierarchy information.  Such
   information could be used for inverse DNS lookups and allowing a Pip
   packet to be associated with an organization.  (Note that the use of
   the Pip ID alone for this purpose can be easily spoofed.  By cross
   checking the Pip ID with the Pip Address prefix, spoofing is harder-
   -as hard as it is with IP--but still easy.  Section 14.2 discusses
   methods for making spoofing harder still, without requiring
   encryption.)

   However, relying on organizational information in the Pip header
   generally complicates ID assignment.  This complication has several
   ramifications.  It makes host autoconfiguration of hosts harder,
   because hosts then have to obtain an assignment from some database
   somewhere (versus creating one locally from an IEEE 802 address, for
   instance).  It means that a host has to get a new assignment if it
   changes organizations.  It is not clear what the ramifications of
   this might be in the case of a mobile host moving through different
   organizations.

   Because of these difficulties, the use of flat Pip IDs is currently
   favored.

   Blocks of Pip ID numbers have been reserved for existing numbering
   spaces, such as IP, IEEE 802, and E.164.  Pip ID numbers have been
   assigned for such special purposes such as "any host", "any router",
   "all hosts on a subnetwork", "all routers on a subnetwork", and so
   on.  Finally, 32-bit blocks of Pip ID numbers have been reserved for
   each country, according to ISO 3166 country code assignments.

6.  Use of DNS

   The Pip near-term architecture uses DNS in roughly the same style
   that it is currently used.  In particular, the Pip architecture
   maintains the two fundamental DNS characteristics of 1) information
   stored in DNS does not change often, and 2) the information returned
   by DNS is independent of who requested it.

   While the fundamental use of DNS remains roughly the same, Pip's use
   of DNS differs from IP's use by degrees.  First, Pip relies on DNS to



Francis                                                        [Page 18]

RFC 1621               Pip Near-term Architecture               May 1994


   hold more types of information than IP [1].  Second, Pip Addresses in
   DNS are expected to change more often than IP addresses, due to
   reassignment of Pip Address prefixes (the providerPart).  To still
   allow aggressive caching of DNS records in the face of more quickly
   changing addressing, Pip has a mechanism of indicating to hosts when
   an address is no longer assigned.  This triggers an authoritative
   query, which overrides DNS caches.  The mechanism consists of PCMP
   Packet Not Delivered messages that indicate explicitly that the Pip
   Address is invalid.

   In what follows, we first discuss the information contained in DNS,
   and then discuss authoritative queries.

6.1  Information Held by DNS

   The information contained in DNS for the Pip architecture is:

   1.  The Pip ID.

   2.  Multiple Pip Addresses

   3.  The destination's mobile host address servers.

   4.  The Public Data Network (PDN) addresses through which the
       destination can be reached.

   5.  The Pip/IP Translators through which the destination (if the
       destination is IP-only) can be reached.

   6.  Information about the providers represented by the destination's
       Pip addresses.  This information includes provider name, the type
       of provider network (such as SMDS, ATM, or SIP), and access
       restrictions on the provider's network.

   The Pip ID and Addresses are the basic units of information required
   for carriage of a Pip packet.

   The mobile host address server tells where to send queries for the
   current address of a mobile Pip host. Note that usually the current
   address of the mobile host is conveyed by the mobile host itself,
   thus a mobile host server query is not usually required.

   The PDN address is used by the entry router of a PDN to learn the PDN
   address of the next hop router.  The entry router obtains the PDN
   address via an option in the Pip packet.  If there are multiple PDNs
   associated with a given Pip Address, then there can be multiple PDN
   addresses carried in the option.  Note that the option is not sent on
   every packet, and that only the PDN entry router need examine the



Francis                                                        [Page 19]

RFC 1621               Pip Near-term Architecture               May 1994


   option.

   The Pip/IP translator information is used to know how to translate an
   IP address into a Pip Address so that the packet can be carried
   across the Pip infrastructure.  If the originating host is IP, then
   the first IP/Pip translator reached by the IP packet must query DNS
   for this information.

   The information about the destination's providers is used to help the
   "source" (either the source host or a Pip Header Server near the
   source host) format an appropriate Pip header with regards to
   choosing a Pip Address [14].  The choice of one of multiple Pip
   Addresses is essentially a policy routing choice.

   More detailed descriptions of the use of the information carried in
   DNS is contained in the relevant sections.

6.2 Authoritative Queries in DNS

   In general, Pip treats addresses as more dynamic entities than does
   IP.  One example of this is how Pip Address prefixes change when a
   subscriber network attaches to a new provider.  Pip also carries more
   information in DNS, any of which can change for various reasons.
   Thus, the information in DNS is more dynamic with Pip than with IP.

   Because of the increased reliance on DNS, there is a danger of
   increasing the load on DNS.  This would be particularly true if the
   means of increasing DNS' dynamicity is by shortening the cache
   holding time by decreasing the DNS Time-to-Live (TTL).  To counteract
   this trend, Pip provides explicit network layer (Pip layer) feedback
   on the correctness of address information.  This allows Pip hosts to
   selectively over-ride cached DNS information by making an
   authoritative query.  Through this mechanism, we actually hope to
   increase the cache holding time of DNS, thus improving DNS' scaling
   characteristics overall.

   The network layer feedback is in the form of a type of PCMP Packet
   Not Delivered (PDN) message that indicates that the address used is
   known to be out-of-date.  Routers can be configured with this
   information, or it can be provided through the routing algorithm
   (when an address is decommissioned, the routing algorithm can
   indicate that this is the reason that it has become unreachable, as
   opposed to becoming "temporarily" unreachable through equipment
   failure).

   Pip hosts consider destination addresses to be in one of four states:





Francis                                                        [Page 20]

RFC 1621               Pip Near-term Architecture               May 1994


   1.  Unknown, but assumed to be valid.

   2.  Reachable (and therefore valid).

   3.  Unreachable and known to be invalid.

   4.  Unreachable, but weakly assumed to be valid.

   The first state exists before a host has attempted communication with
   another host.  In this state, the host queries DNS as normal (that
   is, does not make an authoritative query).

   The second state is reached when a host has successfully communicated
   with another host.  Once a host has reached this state, it can stay
   in it for an arbitrarily long time, including after the DNS TTL has
   expired.  When in this state, there is no need to query DNS.

   A host enters the third state after a failed attempt at communicating
   with another host where the PCMP PND message indicates explicitly
   that the address is known to be invalid.  In this case, the host
   makes an authoritative query to DNS whether or not the TTL has
   expired.  It is this case that allows lengthy caching of DNS
   information while still allowing addresses to be reassigned
   frequently.

   A host enters the fourth state after a failed attempt at
   communicating with another host, but where the address is not
   explicitly known to be invalid.  In this state, the host weakly
   assumes that the address of the destination is still valid, and so
   can requery DNS with a normal (non-authoritative) query.

7.  Type-of-Service (TOS) (or lack thereof)

   One year ago it probably would have been adequate to define a handful
   (4 or 5) of priority levels to drive a simple priority FIFO queue.
   With the advent of real-time services over the Internet, however,
   this is no longer sufficient.  Real-time traffic cannot be handled on
   the same footing as non-real-time.  In particular, real-time traffic
   must be subject to access control so that excess real-time traffic
   does not swamp a link (to the detriment of other real-time and non-
   real-time traffic alike).

   Given that a consensus solution to real- and non-real-time traffic
   management in the internet does not exist, this version of the Pip
   near-term architecture does not specify any classes of service (and
   related queueing mechanisms).  It is expected that Pip will define
   classes of service (primarily for use in the Handling Directive) as
   solutions become available.



Francis                                                        [Page 21]

RFC 1621               Pip Near-term Architecture               May 1994


8.  Routing on (Hierarchical) Pip Addresses

   Pip forwarding in a single router is done based on one or a small
   number of FTIFs.  What this means with respect to hierarchical Pip
   Addresses is that a Pip router is able to forward a packet based on
   examining only part of the Pip Address--often a single level.

   One advantage to encoding each level of the Pip Address separately is
   that it makes handling of addresses, for instance address assignment
   or managing multiple addresses, easier.  Another advantage is address
   lookup speed--the entire address does not have to be examined to
   forward a packet (as is necessary, for instance, with traditional
   hierarchical address encoding).  The cost of this, however, is
   additional complexity in keeping track of the active hierarchical
   level in the Pip header.

   Since Pip Addresses allow reuse of numbers at each level of the
   hierarchy, it is necessary for a Pip router to know which level of
   the hierarchy it is acting at when it retrieves an FTIF.  This is
   done in part with a hierarchy level indicator in the Routing Context
   (RC) field.  RC level is numbered from the top of the hierarchy down.
   Therefore, the top of the hierarchy is RC level = 0, the next level
   down is RC level = 1, and so on.

   The RC level alone, however, is not adequate to keep track of the
   appropriate level in all cases.  This is because different parts of
   the hierarchy may have different numbers of levels, and elements of
   the hierarchy (such as a domain or an area) may exist in multiple
   parts of the hierarchy.  Thus, a hierarchy element can be, say, level
   3 under one of its parents and level 2 under another.

   To resolve this ambiguity, the topological hierarchy is superimposed
   with another set of levels--metalevels [11].  A metalevel boundary
   exists wherever a hierarchy element has multiple parents with
   different numbers of levels, or may with reasonable probability have
   multiple parents with different numbers of levels in the future.

   Thus, a metalevel boundary exists between a subscriber network and
   its provider.  (Note that in general the metalevel represents a
   significant administrative boundary between two levels of the
   topological hierarchy.  It is because of this administrative boundary
   that the child is likely to have multiple parents.) Lower metalevels
   may exist, but usually will not.

   The RC, then, contains a level and a metalevel indicator.  The level
   indicates the number of levels from the top of the next higher
   metalevel.  The top of the global hierarchy is metalevel 0, level 0.
   The next level down (for instance, the level that provides a level of



Francis                                                        [Page 22]

RFC 1621               Pip Near-term Architecture               May 1994


   hierarchy within a provider) is metalevel 0, level 1.  The first
   level of hierarchy under a provider is metalevel 1, level 0, and so
   on.

   To determine the RC level and RC metalevel in a transmitted Pip
   packet, a host (or Pip Header Server) must know where the metalevels
   are in its own Pip Addresses.

   The host compares its source Pip Address with the destination Pip
   Address.  The highest Pip Address component that is different between
   the two addresses determines the level and metalevel.  (No levels
   higher than this level need be encoded in the Routing Directive.)

   Neighbor routers are configured to know if there is a level or
   metalevel boundary between them, so that they can modify the RC level
   and RC metalevel in a transmitted packet appropriately.

8.1  Exiting a Private Domain

   The near-term Pip Architecture provides two methods of exit routing,
   that is, routing inter-domain Pip packets from a source host to a
   network service provider of a private domain [12,15].  In the first
   method, called transit-driven exit routing, the source host leaves
   the choice of provider to the routers.  In the second method, called
   host-driven exit routing, the source host explicitly chooses the
   provider.  In either method, it is possible to prevent internal
   routers from having to carry external routing information.  The exit
   routing bit of the RC indicates which type of exit routing is in
   effect.

   With host-driven exit routing, it is possible for the host to choose
   a provider through which the destination cannot be reached.  In this
   case, the host receives the appropriate PCMP Packet Not Delivered
   message, and may either fallback on transit-driven exit routing or
   choose a different provider.

   When using transit-driven exit routing, there are two modes of
   operation.  The first, called destination-oriented, is used when the
   routers internal to a domain have external routing information, and
   the host has only one provider prefix.  The second, called provider-
   oriented, is used when the routers internal to a domain do not have
   any external routing information or when the host has multiple
   provider prefixes.  (With IP, this case is called default routing.
   In the case of IP, however, default routing does not allow an
   intelligent choice of multiple exit points.)

   With provider-oriented exit routing, the host arbitrarily chooses a
   source Pip Address (and therefore, a provider).  (Note that if the



Francis                                                        [Page 23]

RFC 1621               Pip Near-term Architecture               May 1994


   Pip Header Server is tracking inter-domain routing, then it chooses
   the appropriate provider.) If the host chooses the wrong provider,
   then the border router will redirect the host to the correct provider
   with a PCMP Provider Redirect message.

8.2  Intra-domain Networking

   With intra-domain networking (where both source and destination are
   in the private network), there are two scenarios of concern.  In the
   first, the destination address shares a providerPart with the source
   address, and so the destination is known to be intra-domain even
   before a packet is sent.  In the second, the destination address does
   not share a providerPart with the source address, and so the source
   host doesn't know that the destination is reachable intra-domain.
   Note that the first case is the most common, because the private
   top-level number assignment acts as the common prefix even though it
   isn't advertised globally (see section 4.1).

   In the first case, the Pip Addresses in the Routing Directive need
   not contain the providerPart.  Rather, it contains only the address
   part below the metalevel boundary.  (A Pip Address in an FTIF Chain
   always starts at a metalevel boundary).

   For instance, if the source Pip Address is 1.2.3,4.5.6 and the
   destination Pip Address is 1.2.3,4.7.8, then only 4.7.8 need be
   included for the destination address in the Routing Directive.  (The
   comma "," in the address indicates the metalevel boundary between
   providerPart and subscriberPart.) The metalevel and level are set
   accordingly.

   In the second case, it is desirable to use the Pip Header Server to
   determine if the destination is intra-domain or inter-domain.  The
   Pip Header Server can do this by monitoring intra-domain routing.
   (This is done by having the Pip Header Server run the intra-domain
   routing algorithm, but not advertise any destinations.) Thus, the Pip
   Header Server can determine if the providerPart can be eliminated
   from the address, as described in the last paragraph, or cannot and
   must conform to the rules of exit routing as described in the
   previous section.

   If the Pip Header Server does not monitor intra-domain routing,
   however, then the following actions occur.  In the case of host-
   driven exit routing, the packet will be routed to the stated
   provider, and an external path will be used to reach an internal
   destination.  (The moral here is to not use host-driven exit routing
   unless the Pip Header Server is privy to routing information, both
   internal and external.)




Francis                                                        [Page 24]

RFC 1621               Pip Near-term Architecture               May 1994


   In the case of transit-driven exit routing, the packet sent by the
   host will eventually reach a router that knows that the destination
   is intra-domain.  This router will forward the packet towards the
   destination, and at the same time send a PCMP Reformat Transit Part
   message to the host.  This message tells the host how much of the Pip
   Address is needed to route the packet.

9.  Pip Header Server

   Two new components of the Pip Architecture are the Pip/IP Translator
   and the Pip Header Server.  The Pip/IP Translator is only used for
   transition from IP to Pip, and otherwise would not be necessary.  The
   Pip Header Server, however, is a new architectural component.

   The purpose of the Pip Header Server is to form a Pip Header.  It is
   useful to form the Pip header in a separate box because 1) in the
   future (as policy routing matures, for instance), significant amounts
   of information may be needed to form the Pip header--too much
   information to distribute to all hosts, and 2) it won't be possible
   to evolve all hosts at the same time, so the existence of a separate
   box that can spoon-feed Pip headers to old hosts is necessary.  (It
   is impossible to guarantee that no modification of Pip hosts is
   necessary for any potential evolution, but being able to form the
   header in a server, and hand it to an outdated host, is a large step
   in the right direction.)

   (Note that policy routing architectures commonly if not universally
   require the use of some kind of "route server" for calculating policy
   routes.  The Pip Header Server is, among other things, just this
   server.  Thus, the Pip Header Server does not so much result from the
   fact that Pip itself is more complex than IP or other "IPv7"
   proposals.  Rather, the Pip Header Server reflects the fact that the
   Pip Architecture has more functionality than ROAD architectures
   supported by the simpler proposals.)

   We note that for the near-term architecture hosts themselves will
   by-and-large have the capability of forming Pip headers.  The
   exception to this will be the case where the Pip Header Server wishes
   to monitor inter-domain routing to enhance provider selection.  Thus,
   the Pip Header Server role will be largely limited to evolution (see
   section 16).

9.1  Forming Pip Headers

   Forming a Pip header is more complex than forming an IP header
   because there are many more choices to make.  At a minimum, one of
   multiple Pip Addresses (both source and destination) must be chosen
   [14].  In the near future, it will also be necessary to choose a TOS.



Francis                                                        [Page 25]

RFC 1621               Pip Near-term Architecture               May 1994


   After DNS information about the destination has been received, the
   the following information is available to the Pip header formation
   function.

   1.  From DNS: The destination's providers (either directly connected
       or nearby enough to justify making a policy decision about), and
       the names, types, and access restrictions of those providers.

   2.  From the source host: The application type (and thus, the desired
       service), and the user access restriction classes.

   3.  From local configuration: The source's providers, and the names,
       types, and access restrictions of those providers.

   4.  Optionally from inter-domain routing: The routes chosen by
       inter-domain to all top level providers.  (Note that inter-domain
       routing in the Pip near-term architecture is path-vector.
       Because of this, the Pip Header Server does not obtain enough
       information from inter-domain routing to form a policy route.
       When the technology to do this matures, it can be installed into
       Pip Header Servers.)

       The inter-domain routing information is optional.  If it is used,
       then probably a Pip Header Server is necessary, to limit this
       information to a small number of systems.

   There may also be arbitrary policy information available to the Pip
   header formation function.  This architecture does not specify any
   such information.

   The Pip header formation function then goes through a process of
   forming an ordered list of source/destination Pip Addresses to use.
   The ordering is based on knowledge of the application service
   requirements, the service provided by the source providers, guesses
   or learned information about the service provided by the destination
   providers or by source/destination provider pairs, and the cost of
   using source providers to reach destination providers.  It is assumed
   that the sophistication of forming the ordered list will grow as
   experienced is gained with internet commercialization and real-time
   services.

   The Pip Header formation function then returns the ordered pairs of
   source and destination addresses to the source host in the PHP
   response message, along with an indication of what kind of exit
   routing to use with each pair.  Any additional information, such as
   PDN Address, is also returned.  With this information, the source
   host can now establish communications and properly respond to PCMP
   messages.  Based on information received from PCMP messages,



Francis                                                        [Page 26]

RFC 1621               Pip Near-term Architecture               May 1994


   particularly PCMP Packet Not Delivered messages but also Mobile Host
   messages, the host is able to choose appropriately from the ordered
   list.

   Note that if Pip evolves to the point where the Transit Part of the
   Pip header is no longer compatible with the current Transit Part, and
   the querying host has not been updated to understand the new Transit
   Part, then the PHP response message contains a bit map of the Transit
   Part.  The host puts this bit map into the Transit Part of the
   transmitted Pip header even though it does not understand the
   semantics of the Transit Part.  The Host Version field indicates to
   the Pip Header Server what kinds of transit parts the host can
   understand.

9.2  Pip Header Protocol (PHP)

   The Pip Header Protocol (PHP) is a simple query/response protocol
   used to exchange information between the Pip host and the Pip Header
   Server [6].  In the query, the Pip host includes (among other things)
   the domain name of the destination it wishes to send Pip packets to.
   (Thus, the PHP query serves as a substitute for the DNS query.)

   The PHP query also contains 1) User Access Restriction Classes, 2)
   Application Types, and 3) host version.  The host version tells the
   Pip Header Server what features are installed in the host.  Thus, the
   Pip Header Server is able to determine if the host can format its own
   Pip header based on DNS information, or whether the Pip Header Server
   needs to do it on behalf of the host.  In the future, the PHP query
   will also contain desired TOS (possibly in lieu of Application Type).
   (Note that this information could come from the application.  Thus,
   the application interface to PHP (the equivalent of gethostbyname())
   must pass this information.)

9.3  Application Interface

   In order for a Pip host to generate the information required in the
   PHP query, there must be a way for the application to convey the
   information to the PHP software.  The host architecture for doing
   this is as follows.

   A local "Pip Header Client" (the source host analog to the Pip Header
   Server) is called by the application (instead of the current
   gethostbyname()).  The application provides the Pip Header Client
   with either the destination host domain name or the destination host
   Pip ID, and other pertinent information such as user access
   restriction class and TOS.  The Pip Header Client, if it doesn't have
   the information cached locally, queries the Pip Header Server and
   receives an answer.  (Remember that the Pip Header Server can be co-



Francis                                                        [Page 27]

RFC 1621               Pip Near-term Architecture               May 1994


   resident with the host.)

   Once the Pip Header Client has determined what the Pip header(s) are,
   it assigns a local handle to the headers, returns the handle to the
   application, and configures the Pip packet processing engine with the
   handle and related Pip Headers.  The application then issues packets
   to the Pip layer (via intervening layers such as transport) using the
   local handle.

10.  Routing Algorithms in Pip

   This section discusses the routing algorithm for use with
   (hierarchical) Pip Addresses.

   The architecture for operating routing algorithms in Pip reflects the
   clean partitioning of routing contexts in the Pip header.  Thus,
   routing in the Pip architecture is nicely modularized.

   Within the Hierarchical Pip Address, there are multiple hierarchical
   levels.  Wherever two routers connect, or two levels interface
   (either in a single router or between routers), two decisions must be
   made:  1) what information should be exchanged (that is, what of one
   side's routing table should be propagated to the other side), and 2)
   what routing algorithm should be used to exchange the information?
   The first decision is discussed in section 10.1 below (Routing
   Information Filtering).  The latter decision is discussed here.

   Conceptually, and to a large extent in practice, the routing
   algorithms at each level are cleanly partitioned.  This partition is
   much like the partition between "egp" and "igp" level routing in IP,
   but with Pip it exists at each level of the hierarchy.

   At the top-level of the Pip Address hierarchy, a path-vector routing
   algorithm is used.  Path-vector is more appropriate at the top level
   than link-state because path-vector does not require agreement
   between top-level entities (providers) on metrics in order to be
   loop-free.  (Agreement between the providers is likely to result in
   better paths, but the Pip Architecture does not assume such
   agreement.)

   The top-level path-vector routing algorithm is based on IDRP, but
   enhanced to handle Pip addresses and Pip idiosyncrasies such as the
   Routing Context.  At any level below the top level, it is a local
   decision as to what routing algorithm technology to run.  However,
   the path-vector routing algorithm is generalized so that it can run
   at multiple levels of the Pip Address hierarchy.  Thus, a lower level
   domain can choose to take advantage of the path-vector algorithm, or
   run another, such as a link-state algorithm.  The modified version of



Francis                                                        [Page 28]

RFC 1621               Pip Near-term Architecture               May 1994


   IDRP is called MLPV [10], for Multi-Level Path-Vector (pronounced
   "milpiv").

   Normally, information is exchanged between two separate routing
   algorithms by virtue of the two algorithms co-existing in the same
   router.  For instance, a border router is likely to participate in an
   exchange of routing information with provider routers, and still run
   the routing algorithm of the internal routers.  If the two algorithms
   are different routing technologies (for instance, link-state versus
   distance-vector) then internal conversion translates information from
   one routing algorithm to the form of the other.

   In some cases, however, two routing algorithms that exchange
   information will exist in different routers, and will have to
   exchange information over a link.  If these two algorithms are
   different technologies, then they need a common means of exchanging
   routing information.  While strictly speaking this is a local matter,
   MLPV can also serve as the interface between two disparate routing
   algorithms.  Thus, all routers should be able to run MLPV, if for no
   other reason than to exchange information with other, perhaps
   proprietary, routing protocols.

   MLPV is designed to be extendible with regards to the type of routes
   that it calculates.  It uses the Pip Object parameter identification
   number space to identify what type of route is being advertised and
   calculated [9].  Thus, to add new types of routes (for instance, new
   types of service), it is only necessary to configure the routers to
   accept the new route type, define metrics for that type, and criteria
   for preferring one route of that type over another.

10.1  Routing Information Filtering

   Of course, the main point behind having hierarchical routing is so
   that information from one part of the hierarchy can be reduced when
   passed to another.  In general, reduction (in the form of
   aggregation) takes place when passing information from the bottom of
   the hierarchy up.  However, Pip uses tunneling and exit routing to,
   if desired, allow information from the top to be reduced when it goes
   down.

   When two routers become neighbors, they can determine what
   hierarchical levels they have in common by comparing Pip Addresses.
   For instance, if two neighbor routers have Pip Addresses 1.2.3,4 and
   1.2.8,9.14 respectively, then they share levels 0 and 1, and are
   different at levels below that.  (0 is the highest level, 1 is the
   next highest, and so on.) As a general rule, these two routers
   exchange level 0, level 1, and level 2 routing information, but not
   level 3 or lower routing information.  In other words, both routers



Francis                                                        [Page 29]

RFC 1621               Pip Near-term Architecture               May 1994


   know how to route to all things at the top level (level 0), how to
   route to all level 1 things with "1" as the level 0 prefix, and how
   to route to all level 2 things with "1.2" as the level 1 prefix.

   In the absence of other instructions, two routers will by default
   exchange information about all levels from the top down to the first
   level at which they have differing Pip Addresses.  In practice,
   however, this default exchange is as likely to be followed as not.
   For instance, assume that 1.2.3,4 is a provider router, and
   1.2.8,9.14 is a subscriber router.  (Note that 1.2.8 is the prefix
   given the subscriber by the provider, thus the metalevel boundary
   indicated by the comma.) Assume also that the subscriber network is
   using destination-oriented transit-driven exit routing (see section
   8.1).  Finally, assume that router 1.2.8,9.14 is the subscriber's
   only entry point into provider 1 (other routers provide entry points
   to other providers).

   In this case, 1.2.8,9.14 does not need to know about level 2 or level
   1 areas in the provider (that is, it does not need to know about
   1.2.4..., 1.2.5..., or 1.3..., 1.4..., and so on).  Thus, 1.2.8,9.14
   should be configured to inform 1.2.3,4 that it does not need level 1
   or 2 information.

   As another example, assume still that 1.2.3,4 is a provider and
   1.2.8,9.14 is a subscriber.  However, assume now that the subscriber
   network is using host-driven exit routing.  In this case, the
   subscriber does not even need to know about level 0 information,
   because all exit routing is directed to the provider of choice, and
   having level 0 information therefore does not influence that choice.

11.  Transition

   The transition scheme for Pip has two major components, 1)
   translation, and 2) encapsulation.  Translation is required to map
   the Pip Address into the IP address and vice versa.  Encapsulation is
   used for one Pip router (or host) to exchange packets with another
   Pip router (or host) by tunneling through intermediate IP routers.

   The Pip transition scheme is basically a set of techniques that
   allows existing IP "stuff" and Pip to coexist, but within the
   limitations of IP address depletion (though not within the
   limitations of IP scaling problems).  By this I mean that an IP-only
   host can only exchange packets with other hosts in a domain where IP
   numbers are unique.  Initially this domain includes all IP hosts, but
   eventually will include only hosts within a private domain.  The IP
   "stuff" that can exist includes 1) whole IP domains, 2) individual IP
   hosts, 3) IP-oriented TCPs, and 4) IP-oriented applications.




Francis                                                        [Page 30]

RFC 1621               Pip Near-term Architecture               May 1994


11.1  Justification for Pip Transition Scheme

   Note that all transition to a bigger address require translation.  It
   cannot be avoided.  The major choices one must make when deciding on
   a translation scheme are:

   1.  Will we require a contiguous infrastructure consisting of the new
       protocol, or will we allow tunneling through whatever remains of
       the existing IP infrastructure at any point in time?

   2.  Will we allow global connectivity between IP machines after IP
       addresses are no longer globally unique, or not?  (In other words,
       will we use a NAT scheme or not? [15])

   Concerning question number 1; while it is desirable to move as
   quickly as possible to a contiguous Pip (or SIP or whatever)
   infrastructure, especially for purposes of improved scaling, it is
   fantasy to think that the whole infrastructure will cut over to Pip
   quickly.  Furthermore, during the testing stages of Pip, it is highly
   desirable to be able to install Pip in any box anywhere, and by
   tunneling through IP, create a virtual Pip internet.  Thus, it seems
   that the only reasonable answer to question number 1 is to allow
   tunneling.

   Concerning question number 2; it is highly desirable to avoid using a
   NAT scheme.  A NAT (Network Address Translation) scheme is one
   whereby any two IP hosts can communicate, even though IP addresses
   are not globally unique.  This is done by dynamically mapping non-
   unique IP addresses into unique ones in order to cross the
   infrastructure.  NAT schemes have the problems of increased
   complexity to maintain the mappings, and of translating IP addresses
   that reside within application data structures (such as the PORT
   command in FTP).

   This having been said, it is conceivable that the new protocol will
   not be far enough along when IP addresses are no longer unique, and
   therefore a NAT scheme becomes necessary.  It is possible to employ a
   NAT scheme at any time in the future without making it part of the
   intended transition scheme now.  Thus, we can plan for a NATless
   transition now without preventing the potential use of NAT if it
   becomes necessary.

11.2  Architecture for Pip Transition Scheme

   The architecture for Pip Transition is that of a Pip infrastructure
   surrounded by IP-only "systems".  The IP-only "systems" surrounding
   Pip can be whole IP domains, individual IP hosts, an old TCP in an
   otherwise Pip host, or an old application running on top of a Pip-



Francis                                                        [Page 31]

RFC 1621               Pip Near-term Architecture               May 1994


   smart TCP.

   The Pip infrastructure will initially get its internal connectivity
   by tunneling through IP.  Thus, any Pip box can be installed
   anywhere, and become part of the Pip infrastructure by configuration
   over a "virtual" IP.  Of course, it is desirable that Pip boxes be
   directly connected to other Pip boxes, but very early on this is the
   exception rather than the rule.

   Two neighbor Pip systems tunneling through IP simply view IP as a
   "link layer" protocol, and encapsulate Pip over IP just as they would
   encapsulate Pip over any other link layer protocol.  In particular,
   the hop-count field of Pip is not copied into the Time-to-Live field
   of IP.  There is no automatic configuration of neighbor Pip systems
   over IP.  Manual configuration (and careful "virtual topology"
   engineering) is required.  Note that ICMP messages from a IP router
   in a tunnel is not translated into a PCMP message and sent on.  ICMP
   messages are sinked at the translating router at the head of the
   tunnel.  The information learned from such ICMP messages, however,
   may be used to determine unreachability of the other end of the
   tunnel, and may there result in PCMP message on later packets.

   In the remainder of this section, we do not distinguish between a
   virtual Pip infrastructure on IP, and a pure Pip infrastructure.

   Given the model of a Pip infrastructure surrounded by IP, there are 5
   possible packet paths:

   1.  IP - IP

   2.  IP - Pip - IP

   3.  IP - Pip

   4.  Pip - IP

   5.  Pip - Pip

   The first three paths involve packets that originate at IP-only
   hosts.  In order for an IP host to talk to any other host (IP or
   not), the other host must be addressable within the context of the IP
   host's 32-bit IP address.  Initially, this "IP-unique" domain will
   include all IP hosts.  When IP addresses become no longer unique, the
   IP-unique domain will include a subset of all hosts.  At a minimum,
   this subset will include those hosts in the IP-host's private domain.
   However, it makes sense also to arrange for the set of all "public"
   hosts, basically anonymous ftp servers and mail gateways, to be in
   this subset.  In other words, a portion of IP address space should be



Francis                                                        [Page 32]

RFC 1621               Pip Near-term Architecture               May 1994


   set aside to remain globally unique, even though other parts of the
   address space are being reused.

11.3  Translation between Pip and IP packets

   Paths 2 and 4 involve translation from Pip to IP.  This translation
   is straightforward, as all the information needed to create the IP
   addresses is in the Pip header.  In particular, Pip IDs have an
   encoding that allows them to contain an IP address (again, one that
   is unique within an IP-unique domain).  Whenever a packet path
   involves an IP host on either end, both hosts must have IP addresses.
   Thus, translating from Pip to IP is just a matter of extracting the
   IP addresses from the Pip IDs and forming an IP header.

   Translating from an IP header to a Pip header is more difficult,
   because the 32-bit IP address must be "translated" into a 64-bit Pip
   ID and a Pip Address.  There is no algorithm for making this
   translation.  A table mapping IP addresses (or, rather, network
   numbers) to Pip IDs and Pip Addresses is required.  Since such a
   table must potentially map every IP address, we choose to use dynamic
   discovery and caching to maintain the table.  We choose also to use
   DNS as the means of discovering the mappings.

   Thus, DNS contains records that map IP address to Pip ID and Pip
   Address.  In the case where the host represented by the DNS record is
   a Pip host (packet path 3), the Pip ID and Pip Address are those of
   the host.  In the case where the host represented by the DNS record
   is an IP-only host (packet paths 2 and 4), the Pip Address is that of
   the Pip/IP translating gateway that is used to reach the IP host.
   Thus, an IP-only domain must at least be able to return Pip
   information in its DNS records (or, the parent DNS domain must be
   able to do it on behalf of the child).

   With paths 2 and 3 (IP-Pip-IP and IP-Pip), the initial translating
   gateway (IP to Pip) makes the DNS query.  It stores the IP packet
   while waiting for the answer.  The query is an inverse address (in-
   addr) using the destination IP address.  The translating gateway can
   cache the record for an arbitrarily long period, because if the
   mapping ever becomes invalid, a PCMP Invalid Address message flushes
   the cache entry.

   In the case of path 4 (Pip-IP), however, the Pip Address of the
   translating gateway is returned directly to the source host--
   piggybacked on the DNS record that is normally returned.  Thus this
   scheme incurs only a small incremental cost over the normal DNS
   query.





Francis                                                        [Page 33]

RFC 1621               Pip Near-term Architecture               May 1994


11.4  Translating between PCMP and ICMP

   The only ICMP/PCMP messages that are translated are the Destination
   Unreachable, Echo, and PTMU Exceeded messages.  The portion of the
   offending IP/Pip header that is attached to the ICMP/PCMP message is
   not translated.

11.5  Translating between IP and Pip Routing Information

   It is not necessary to pass IP routing information into the Pip
   infrastructure.  The mapping of IP address to Pip Address in DNS
   allows Pip to find the appropriate gateway to IP in the context of
   Pip addresses only.

   It is impossible to pass Pip routing information into IP routers,
   since IP routers cannot understand Pip addresses.  IP domains must
   therefore use default routing to reach IP/Pip translators.

11.6  Old TCP and Application Binaries in Pip Hosts

   A Pip host can be expected to have an old TCP above it for a long
   time to come, and a new (Pip-smart) TCP can be expected to have old
   application binaries running over it for a long time to come.  Thus,
   we must have some way of insuring that the TCP checksum is correctly
   calculated in the event that one or both ends is running Pip, and one
   or both ends has an old TCP binary.  In addition, we must arrange to
   allow applications to interface with TCP using a 32-bit "address"
   only, even though those 32 bits get locally translated into Pip
   Addresses and IDs.

   As stated above, in all cases where a Pip host is talking to an IP-
   only host, the Pip host has a 32-bit IP address. This address is
   embedded in the Pip ID such that it can be identified as an IP
   address from inspection of the Pip ID alone.

   The TCP pseudo-header is calculated using the Payload Length and
   Protocol fields, and some or all of the Source and Dest Pip IDs.  In
   the case where both Source and Dest Pip IDs are IP-based, only the
   32-bit IP address is included in the pseudo-header checksum
   calculation.  Otherwise, the full 64 bits are used.  (Note that using
   the full Payload Length and Protocol fields does not fail when old
   TCP binaries are being used, because the values for those fields must
   be within the 16-bit and 8-bit limits for TCP to correctly operate.)

   The reason for only using 32 bits of the Pip ID in the case of both
   ends using an IP address is that an old TCP will use only 32 bits of
   some number to form the pseudo-header.  If the entire 64 bits of the
   Pip ID were used, then there would be cases where no 32-bit number



Francis                                                        [Page 34]

RFC 1621               Pip Near-term Architecture               May 1994


   could be used to insure that the correct checksum is calculated in
   all cases.

   Note that in the case of an old TCP on top of Pip, "Pip" (actually, a
   Pip daemon) must create a 32-bit number that can both be used to 1)
   allow the Pip layer to correctly associate a packet from the TCP
   layer with the right Pip header, and 2) cause the TCP layer to
   calculate the right checksum.  (This number is created when the
   application initiates a DNS query.  A Pip daemon intervenes in this
   request, calculates a 32 bit number that the application/TCP can use,
   and informs the Pip layer of the mapping between this 32 bit number
   and the full Pip header.)

   When the destination host is an IP only host, then this 32-bit number
   is nothing more than the IP address.  When the destination host is a
   Pip host, then this 32-bit number is some number generated by Pip to
   "fool" the old TCP into generating the right checksum.  This 32-bit
   number can normally be the same as the lower 32 bits of the Pip ID.
   However, it is possible that two or more active TCP connections is
   established to different hosts whose Pip IDs have the same lower 32
   bits.  In this case, the Pip layer must generate a different 32-bit
   number for each connection, but in such a way that the sum of the two
   16-bit components of the 32-bit numbers are the same as the sum of
   the two 16-bit components of the lower 32 bits of the Pip IDs.

   In the case where an old Application wants to open a socket using an
   IP address handed to it (by the user or hard-coded), and not using a
   domain name, then it must be assumed that this IP address is valid
   within the IP-unique domain.  To form a Pip ID out of this 32-bit
   number, the host appends the high-order 24 bits of its own Pip ID,
   plus the IP-address-identifier-byte value, to the 32-bit IP address.

11.7  Translating between Pip Capable and non-Pip Capable DNS Servers

   In addition to transitioning "Pip-layer" packets, it is necessary to
   transition DNS from non-Pip capable to Pip capable.  During
   transition there will be name servers in DNS that only understand IP
   queries and those that understand both Pip and IP queries.  This
   means there must be a mechanism for Pip resolvers to detect whether a
   name server is Pip capable, and vice versa.  Also, a name server, if
   it provides recursive service, must be able to translate Pip requests
   to IP requests.  (Pip-capable means a name server understands Pip and
   existing IP queries.  It does not necessarily mean the name server
   uses the Pip protocol to communicate.)

   New resource records have been defined to hold Pip identifiers and
   addresses, and other information [1].  These resource records must be
   queried using a new opcode in the DNS query packet header.  Existing



Francis                                                        [Page 35]

RFC 1621               Pip Near-term Architecture               May 1994


   resource records can be queried using both the old and new header
   formats.  Name servers that are not Pip-capable will respond with a
   format error to queries with the new opcode.  Thus, a resolver can
   determine dynamically whether a name server is Pip-capable, by
   sending it a Pip query and noting the response.  This only need be
   done once, when querying a server for the "first" time, and the
   outcome can be cached along with the name server's address.

   Using a new opcode for making Pip queries also helps name servers
   determine whether a resolver is Pip-capable (it is not always not
   obvious from the type of query made since many queries are common to
   to IP and Pip).  Determining whether a resolver is Pip-capable is
   necessary when responding with address information that is not
   explicitly requested by the query.  An important example of this is
   when a name server makes a referral to another name server in a
   response: if the request comes from a Pip resolver, name server
   addresses will be returned as Pip identifier/address resource
   records, otherwise the addresses will be returned as IP A resource
   records.

   Those servers that are Pip-capable and provide recursive service must
   translate Pip requests to IP requests when querying an IP name
   server.  For most queries, this will just mean modifying the opcode
   value in the query header to reflect an IP query, rather than a Pip
   query.  (Most queries are identical in IP and Pip.) Other queries,
   notably the query for Pip identifier/address information, must be
   translated into its IP counterpart, namely, an IP A query.  On
   receipt of an answer from an IP name server, a Pip name server must
   translate the query header and question section back to its original,
   and format the answer appropriately.  Again, for most queries, this
   will be a trivial operation, but responses containing IP addresses,
   either as a result of an explicit query or as additional information,
   must be formatted to appear as a valid Pip response.

   Pip-capable name servers that provide recursive name service should
   also translate IP address requests into Pip identifier/address
   requests when querying a Pip-capable name server.  (A host's IP
   address can be deduced from the host's Pip identifier.) This enables
   a Pip-capable name server to cache all relevant addressing
   information about a Pip host in the first address query concerning
   the host.  Caching partial information is undesirable since the name
   server, using the current DNS caching strategy, would return only the
   cached information on a future Pip request, and IP, rather than Pip,
   would be used to communicate with the destination host.







Francis                                                        [Page 36]

RFC 1621               Pip Near-term Architecture               May 1994


12.  Pip Address and ID Auto-configuration

   One goal of Pip is to make networks as easy to administer as
   possible, especially with regards to hosts.  Certain aspects of the
   Pip architecture make administration easier.  For instance, the ID
   field provides a network layer "anchor" around which address changes
   can be administered.

   This section discusses three aspects of autoconfiguration; 1)
   domain-wide Pip Address prefix assignment, 2) host Pip Address
   assignment, and 3) host Pip ID assignment.

12.1  Pip Address Prefix Administration

   A central premise behind the use of provider-rooted hierarchical
   addresses is that domain-wide address prefix assignment and re-
   assignment is straight-forward.  This section describes that process.

   Pip Address prefix administration limits required manual prefix
   configuration to DNS and border routers.  This is the minimum
   required manual configuration possible, because both border routers
   and DNS must be configured with prefix information for other reasons.
   DNS must be configured with prefix information so that it can reply
   to address queries.  DNS files are structured so that the prefix is
   administered in only one place (that is, every host record does not
   have to be changed to create a new prefix).  Border routers must be
   configured with prefix information in order to advertise exit routes
   internally.

   Note in particular that no internal (non-border) routers or hosts
   need ever be manually configured with any externally derived
   addressing information.  All internal routers that are expected to
   fall under a common provider-prefix must, however, be configured with
   a "group ID" taken from the Pip ID space.  (This group ID is not a
   multicast ID per se.  Rather, it is an identifier that allows prefix
   updates to be targetted to a specific set of routers.)

   Each border router is configured with the following information.

   1.  The type of exit routing for the domain.  This tells the border
       router whether or not it needs to advertise external routes
       internally.

   2.  The address prefix of the providers that the border is directly
       connected to.  This prefix information includes any metalevel
       boundaries above the subscriber/provider metalevel boundary
       (called simply the subscriber metalevel).




Francis                                                        [Page 37]

RFC 1621               Pip Near-term Architecture               May 1994


   3.  Other information about the provider (provider name, type, user
       access restriction classes).

   4.  A list of common-provider-prefix group IDs that should receive the
       auto-configuration information. (The default is that only systems
       that share a group ID with the border router will receive the
       information.)

   This information is injected into the intra-domain routing algorithm.
   It is automatically spread to all routers indicated by the group ID
   list.  This way, the default behavior is for the information to be
   automatically constrained to the border router's "area".

   When a non-border router receives this information, it 1) records the
   route to the providers in its forwarding table, and 2) advertises the
   information to hosts in the router discovery protocol [8].  Thus
   hosts learn not only their complete address, but also information on
   how to do exit routing and on how to choose source addresses.

12.2  Host Autoconfiguration

   There are three phases of host autoconfiguration:

   1.  The host locally creates a flat unique Pip ID (probably globally
       unique but at least unique on the attached subnet).

   2.  The host learns its Pip Addresses.

   3.  The host optionally obtains a hierarchical, organizationally
       meaningful Pip ID and a domain name from a Pip ID/domain name
       assignment service.  This service updates DNS.

   Item three is optional.  If Pip ID and domain name assignment
   services are not installed, then the host must obtain its domain name
   and, if necessary, Pip ID, from static configuration.  Each of the
   three phases are described below.

12.2.1  Host Initial Pip ID Creation

   When a host boots, it can form an ID based only on local information.
   If the host has an IEEE 802 number, either from an IEEE 802 interface
   or from an internal identifier, then it can create a globally unique
   Pip ID from the IEEE 802 Pip ID type [4].  Otherwise, the host can
   create an ID from the IEEE 802 space using its subnet (link layer)
   address.  This latter ID is only guaranteed to be locally unique.






Francis                                                        [Page 38]

RFC 1621               Pip Near-term Architecture               May 1994


12.2.2  Host Pip Address Assignment

   Unless a host does not wish to use ID-tailed Pip Addresses (see
   section 4.1.2), host Pip Address assignment is trivial.  (The near-
   term Pip Architecture doesn't specify a means for a host to obtain a
   non-ID-tailed Pip Address.) When a host attaches to a subnet, it
   learns the Pip Address of the attached routers through router
   discovery.

   The host simply adopts these Pip Addresses as its own.  The Pip
   Address gets a packet to the host's subnet, and the host's Pip ID is
   used to route across the subnet.  When the routers advertise new
   addresses (for instance, because of a new provider), the host adopts
   the new addresses.

12.2.3  Pip ID and Domain Name Assignment

   Once the host has obtained its Pip Addresses and an at-least-
   locally-unique Pip ID, it can exchange packets with an ID/Domain Name
   (ID/DN) assignment service.  If the host locally created a globally
   unique Pip ID (using an IEEE 802 number), and the organization it
   belongs to does not use organizationally structured Pip IDs (which
   should normally be the case) then it only needs to obtain a domain
   name.  The ID/DN assignment service is reachable at a well-known
   anycast address [4].  Thus, the host is able to start exchanging
   packets with the ID/DN assignment service without any additional
   configuration.

   If there is no ID/DN assignment service available, then the host must
   obtain it's organizational ID or DNS name in a non-automatic way.  If
   the ID/DN assignment service is down, the host must temporarily
   suffice with just a Pip ID and Address.  The host can periodically
   try to reach the ID/DN assignment service.

   The ID/DN assignment service must coordinate with DNS.  When the
   ID/DN assignment service creates a new ID or domain name to assign to
   a new host, it must know which IDs and domain names are available for
   assignment.  It must also update DNS with the new information.

   The design of this service is left for further study.











Francis                                                        [Page 39]

RFC 1621               Pip Near-term Architecture               May 1994


13.  Pip Control Message Protocol (PCMP)

   The Pip analog to ICMP is PCMP [7].  The near-term Pip architecture
   defines the following PCMP messages:

   1.  Local Redirect

   2.  Packet Not Delivered

   3.  Echo

   4.  Parameter Problem

   5.  Router Discovery

   6.  PMTU Exceeded

   7.  Provider Redirect

   8.  Reformat Transit Part

   9.  Unknown Parameter

   10. Host Mobility

   11. Exit PDN Address

   The Local Redirect, Echo, and Parameter Problem PCMP messages operate
   almost identically to their ICMP counterparts.

   The Packet Not Delivered PCMP message serves the role of ICMP's
   Destination Unreachable.  The Packet Not Delivered, has two major
   differences.  First, it is more general in that it indicates the
   hierarchy level of unreachability (rather than explicit host, subnet,
   network unreachability as with IP).  Second, it indicates when an
   address is known to be invalid, thus allowing for more intelligent
   use of DNS (see section 6.2).

   The Router Discovery PCMP message operates as ICMP's, with the
   exception that a host derives its Pip Address from it.

   The PMTU Exceeded message operates as ICMP's, with the exception that
   the Pip header size of the offending Packet is also given.  This
   allows the source host transport to determine how much smaller the
   packet PMTU should be from the advertised subnet PMTU.  Note that if
   an occasional option, such as the PDN Address option, needs to be
   attached to one of many packets, and that this option makes the
   packet larger than the PMTU, then it is not necessary to modify the



Francis                                                        [Page 40]

RFC 1621               Pip Near-term Architecture               May 1994


   MTU coming from transport.  Instead, that packet can be fragmented by
   the host's Pip forwarding engine.  (Pip specifies
   fragmentation/reassembly for hosts but not for routers.  The
   fragmentation information is in a Pip Option.)

   The Provider Redirect, Invalid Address, Reformat Transit Part,
   Unknown Parameter, Host Mobility, and Exit PDN Address PCMP messages
   are new.

   The Provider Redirect PCMP message is used to inform the source host
   of a preferable exit provider to use when provider-rooted, transit-
   driven exit routing is used (see section 8.1).

   The Invalid Address PCMP message is used to inform the source host
   that none of the IDs of the destination host match that of the Pip
   packet.  The purpose of this message is to allow for authoritative
   DNS requests (see section 6.2).

   The Reformat Transit Part PCMP message has both near-term Pip
   architecture functions and evolution functions.  Near-term, the
   Reformat Transit Part PCMP message is used to indicate to the source
   whether it has too few or too many layers of address in the Routing
   Directive (see section 8.2).  Long-term, the Reformat Transit Part
   PCMP message is able to arbitrarily modify the transit part
   transmitted by the host, as encoded by a bit string.

   The Unknown Parameter PCMP message is used to inform the source host
   that the router does not understand a parameter in either the
   Handling Directive, the Routing Context, or the Transit Options.  The
   purpose of this message is to assist evolution (see section 16.1).

   The Host Mobility PCMP message is sent by a host to inform another
   host (for instance, the host's Mobile Address Server) that it has a
   new address (see section 14).  The main use of this packet is for
   host mobility, though it can be used to manage any address changes,
   such as because of a new prefix assignment.

   The Exit PDN Address PCMP message is used to manage the function
   whereby the source host informs the PDN entry router of the PDN
   Address of the exit PDN system (see section 15).

   When a router needs to send a PCMP message, it sends it to the source
   Pip Address.  If the Pip header is in a tunnel, then the PCMP message
   is sent to the router that is the source of the tunnel.  Depending on
   the situation, this may result in another PCMP message from the
   source of the tunnel to the true source (for instance, if the source
   of the tunnel finds that the dest of the tunnel can't be reached, it
   may send a Packet Not Delivered to the source host).



Francis                                                        [Page 41]

RFC 1621               Pip Near-term Architecture               May 1994


14.  Host Mobility

   Depending on how security conscience a host is, and what security
   mechanisms a host has available, mobility can come from Pip "for
   free".  If a host is willing to accept a packet by just looking at
   source and destination Pip ID, and if the host simply records the
   source Pip Address on any packet it receives as the appropriate
   return address to the source Pip ID, then mobility comes
   automatically.

   That is, when a mobile host gets a new Pip Address, it simply puts
   that address into the next packet it sends.  When the other host
   receives it, it records the new Pip Address, and starts sending
   return packets to that address.  The security aspect of this is that
   this type of operation leads to an easy way to spoof the (internet
   level) identity of a host.  That is, absent any other security
   mechanisms, any host can write any Pip ID into a packet.  (Cross-
   checking a source Pip ID against the source Pip Address at least
   makes spoofing of this sort as hard as with IP. This is discussed
   below.)

   The above simple host mobility mechanism does not work in the case
   where source and destination hosts obtain new Pip Addresses at the
   same time and the old Pip addresses no longer work, because neither
   is able to send its new address information directly to the other.
   Furthermore, if a host wishes to be more secure about authenticating
   the source Pip ID of a packet, then the above mechanism also is not
   satisfactory.  In what follows, the complete host mobility mechanism
   is described.

   Pip uses the Mobile Host Server and the PCMP Host Mobility message to
   manage host mobility;

   The Mobile Host Server is a non-mobile host (or router acting as a
   host) that keeps track of the active address of a mobile host.  The
   Pip ID and Address of the Mobile Host Server is configured into the
   mobile host, and in DNS.  When a host X obtains information from DNS
   about a host Y, the Pip ID and Address of host Y's Mobile Host Server
   is among the information.  (Also among the information is host Y's
   "permanent" address, if host Y has one.  If host Y is so mobile that
   it doesn't have a permanent address, then no permanent address is
   returned by DNS.  In particular, note that DNS is not intended to
   keep track of a mobile host's active address.)

   Given the destination host's (Y) permanent ID and Address, and the
   Mobile Host Server's permanent IDs and Addresses, the source host (X)
   proceedes as follows.  X tries to establish communications with Y
   using one of the permanent addresses.  If this fails (or if at any



Francis                                                        [Page 42]

RFC 1621               Pip Near-term Architecture               May 1994


   time X cannot contact Y), X sends a PCMP Mobile Host message to the
   Mobile Host Server requesting the active address for Y.  (Note that X
   can determine that it cannot contact Y from receipt of a PCMP
   Destination Unreachable or a PCMP Invalid Address message.)

   The Mobile Host Server responds to X with the active Pip Addresses of
   Y.  (Of course, Y must inform its Mobile Host Server(s) of its active
   Pip Addresses when it knows them.  This also is done using the PCMP
   Mobile Host message.  Y also informs any hosts that it is actively
   communicating with, using either a regular Pip packet or with a PCMP
   Mobile Host message.  Thus, usually X does not need to contact the
   Mobile Host Server to track Y's active address.)

   If the address that X already tried is among those returned by Y,
   then the source host has the option of either 1) continuing to try
   the same Pip Address, 2) trying another of Y's Pip Addresses, 3)
   waiting and querying the Mobile Host Server again, or 4) giving up.

   If the Mobile Host Server indicates that Y has new active Pip
   Addresses, then X chooses among these in the same manner that it
   chooses among multiple permanent Pip Addresses, and tries to contact
   Y.

14.1  PCMP Mobile Host message

   There are two types of PCMP Mobile Host messages, the query and the
   response.  The query consists of the Pip ID of the host for which
   active Pip Address information is being requested.

   The response consists of a Pip ID, a sequence number, a set of Pip
   Addresses, and a signature field.  The set of Pip Addresses includes
   all currently usable addresses of the host indicated by the Pip ID.
   Thus, the PCMP Mobile Host message can be used both to indicate a
   newly obtained address, and to indicate that a previous address is no
   longer active (by that addresses' absence in the set).

   The sequence number indicates which is the most recent information.
   It is needed to deal with the case where an older PCMP Mobile Host
   response is received after a newer one.

   The signature field is a value that derives from encrypting the
   sequence number and the set of Pip Addresses.  For now, the
   encryption algorithms used, how to obtain keys, and so on are for
   further study.







Francis                                                        [Page 43]

RFC 1621               Pip Near-term Architecture               May 1994


14.2  Spoofing Pip IDs

   This section discusses host mechanisms for decreasing the probability
   of Pip ID spoofing.  The mechanisms provided in this version of the
   near-term Pip architecture are no more secure than DNS itself.  It is
   hoped that mechanisms and the corresponding infrastructure needed for
   better internetwork layer security can be installed with whatever new
   IP protocol is chosen.

   After a host makes a DNS query, it knows:

   1.  The destination host's Pip ID,

   2.  The destination host's permanent Pip Addresses, and

   3.  The destination host's Mobile Host Server's Pip ID and Addresses.

   Note that the DNS query can be a normal one (based on domain name) or
   an inverse query (based on Pip ID or Pip Address, though the latter
   is more likely to succeed, since the Pip ID may be flat and therefore
   not suitable for an inverse lookup).  The inverse query is done when
   the host did not initiate the packet exchange, and therefore doesn't
   know the domain name of the remote (initiating) host.

   If the destination host is not mobile, then the source host can check
   the source Pip Address, compare it with those received from DNS, and
   reject the packet if it does not match.  This gives spoof protection
   equal to that of IP.

   If the destination host is mobile and obtains new Pip Addresses, then
   the source host can check the validity of the new Pip Address by
   sending a PCMP Mobile Host query to the Mobile Host Server learned
   from DNS.  The set of Pip Addresses learned from the Mobile Address
   Server is then used for subsequent validation.

15.  Public Data Network (PDN) Address Discovery

   One of the problems with running Pip (or any internet protocol) over
   a PDN is that of the PDN entry Pip System discovering the PDN Address
   of the appropriate PDN exit Pip System.  This problem is solved using
   ARP in small, broadcast LANs because the broadcast mechanism is
   relatively cheap.  This solution is not available in the PDN case,
   where the number of attached systems is very large, and where
   broadcast is not available (or is not cheap if it is).

   For the case where the domain of the destination host is attached to
   a PDN, the problem is nicely solved by distributing the domain's exit
   PDN Address information in DNS, and then having the source host



Francis                                                        [Page 44]

RFC 1621               Pip Near-term Architecture               May 1994


   convey the exit PDN Address to the PDN entry router in a Pip option.

   The DNS of the destination host's domain contains the PDN Addresses
   for the domain.  When DNS returns a record for the destination host,
   the record associates zero or more PDN Addresses with each Pip
   Address.  There can be more than one PDN address associated with a
   given PDN, and there can be more than on PDN associated with a given
   Pip Address.  This latter case occurs when more than one hierarchical
   component of the Pip Address each represents a separate PDN.  It is
   expected that in almost all cases, there will be only one (or none)
   PDN associated with any Pip address.

   (Note that, while the returned DNS record associates the PDN
   Addresses with a single Pip Address, in general the PDN Address will
   apply to a set of Pip Addresses--those for all hosts in the domain.
   The DNS files are structured to reflect this grouping in the same way
   that a single Pip Address prefix in DNS applies to many hosts.
   Therefore, every individual host entry in the DNS files does not need
   to have separate PDN Addresses typed in with it.  This simplifies
   configuration of DNS.)

   When the source host sends the first packet to a given destination
   host, it attaches the PDN Addresses, one per PDN, to the packet in an
   option.  (Note that, because of the way that options are processed in
   Pip packets, no router other than the entry PDN router need look at
   the option.) When the entry router receives this packet, it
   determines that it is the entry router based on the result of the
   FTIF Chain lookup.

   It retrieves the PDN Address from the option, and caches it locally.
   The cache entry can later by retrieved using either the destination
   Pip ID or the destination Pip Address as the cache index.

   The entry router sends the source host a PCMP Exit PDN Address
   message indicating that it has cached the information.  If there are
   multiple exit PDN Addresses, then the source host can at this time
   inform the entry PDN router of all the PDN addresses.  The entry PDN
   router can either choose from these to setup a connection, or cache
   them to recover from the case where the existing connection breaks.

   Finally, the entry PDN router delivers the Pip packet (perhaps by
   setting up a connection) to the PDN Address indicated.

   When a PDN entry router receives a Pip packet for which it doesn't
   know the exit PDN address (and has no other means of determining it,
   such as shortcut routing), it sends a PCMP Exit PDN Address query
   message to the originating host.  This can happen if, for instance,
   routing changes and directs the packets to a new PDN entry router.



Francis                                                        [Page 45]

RFC 1621               Pip Near-term Architecture               May 1994


   When the source host receives the PCMP Exit PDN Address query
   message, it transmits the PDN Addresses to the entry PDN router.

15.1  Notes on Carrying PDN Addresses in NSAPs

   The Pip use of PDN Address carriage in the option or PCP Exit PDN
   Address message solves two significant problems associated with the
   analogous use of PDN Address-based NSAPs.

   First, there is no existing agreement (standards or otherwise) that
   the existence of of a PDN Address in an NSAP address implies that the
   identified host is reachable behind the PDN Address.  Thus, upon
   receiving such an NSAP, the entry PDN router does not know for sure,
   without explicit configuration information, whether or not the PDN
   Address can be used at the lower layer.  Solution of this problem
   requires standards body agreement, perhaps be setting aside
   additional AFIs to mean "PDN Address with topological significance".

   The second, and more serious, problem is that a PDN Address in an
   NSAP does not necessarily scale well.  This is best illustrated with
   the E.164 address.  E.164 addresses can be used in many different
   network technologies--telephone network, BISDN, SMDS, Frame Relay,
   and other ATM.  When a router receives a packet with an E.164-based
   NSAP, the E.164 address is in the most significant part of the NSAP
   address (that is, contains the highest level routing information).
   Thus, without a potentially significant amount of routing table
   information, the router does not know which network to send the
   packet to.  Thus, unless E.164 addresses are assigned out in blocks
   according to provider network, it won't scale well.

   A related problem is that of how an entry PDN router knows that the
   PDN address is meant for the PDN it is attached to or some other PDN.
   With Pip, there is a one-to-one relationship between Pip Address
   prefix and PDN, so it is always known.  With NSAPs, it is not clear
   without the potentially large routing tables discussed in the
   previous paragraph.

16.  Evolution with Pip

   The fact that we call this architecture "near-term" implies that we
   expect it to evolve to other architectures.  Thus it is important
   that we have a plan to evolve to these architectures.  The Pip near-
   term architecture includes explicit mechanisms to support evolution.

   The key to evolution is being able to evolve any system at any time
   without destroying old functionality.  Depending on what the new
   functionality is, it may be immediately useful to any system that
   installs it, or it may not become useful until a significant number



Francis                                                        [Page 46]

RFC 1621               Pip Near-term Architecture               May 1994


   or even a majority of systems install it.  None-the-less, it is
   necessary to be able to install it piece-wise.

   The Pip protocol itself supports evolution through the following
   mechanisms [2]:

   1.  Tunneling.  This allows more up-to-date routers to tunnel less
       up-to-date routers, thus allowing for incremental router
       evolution.  (Of course, by virtue of encapsulation, tunneling is
       always an evolution option, and indeed tunneling through IP is
       used in the Pip transition.  However, Pip's tunneling encoding is
       efficient because it doesn't duplicate header information.)

       The only use for Pip tunneling in the Pip near-term architecture
       is to route packets through the internal routers of a transit
       domain when the internal routers have no external routing
       information.  It is assumed that enhancements to the Pip
       Architecture that require tunneling will have their own means of
       indicating when forming a tunnel is necessary.

   2.  Host independence from routing information.  Since a host can
       receive packets without understanding the routing content of the
       packet, routers can evolve without necessarily requiring hosts to
       evolve at the same pace.

       In order to allow hosts to send Pip packets without understanding
       the contents of the routing information (in the Transit Part), the
       Pip Header Server is able to "spoon-feed" the host the Pip header.

       If the Pip Header Server determines that the host is able to form
       its own Pip header (as will usually be the case with the near-term
       Pip architecture), the Pip Header is essentially a null function.
       It accepts a query from the host, passes it on to DNS, and returns
       the DNS information to the host.

       If the Pip Header Server determines that the host is not able to
       form its own Pip header, then the Pip Header Server forms one on
       behalf of the host.  In one mode of operation, the Pip Header
       Server gives the host the values of some or all Transit Part
       fields, and the host constructs the Transit Part.  This allows for
       evolution within the framework of the current Transit Part.  In
       another mode, the Pip Header Server gives the host the Transit
       Part as a simple bit field.  This allows for evolution outside the
       framework of the current Transit Part.

       In addition to the Pip Header Server being able to spoon-feed the
       host a Transit Part, routers are also able to spoon-feed hosts a
       Transit Part, in case the original Transit Part needs to be



Francis                                                        [Page 47]

RFC 1621               Pip Near-term Architecture               May 1994


       modified, using the PCMP Reformat Transit Part message.

   3.  Separation of handling from routing.  This allows one aspect to
       evolve independently of the other.

   4.  Flexible Handling Directive, Routing Context, and Options
       definition.  This allows new handling, routing, and option types
       to be added and defunct ones to be removed over time (see section
       16.1 below).

   5.  Fast and general options processing.  Options processing in Pip is
       fast, both because not every router need look at every option, and
       because once a router decides it needs to look at an option, it
       can find it quickly (does not require a serial search).  Thus the
       oft-heard argument that a new option can't be used because it will
       slow down processing in all routers goes away.

    Pip Options can be thought of as an extension of the Handling
    Directive (HD).  The HD is used when the handling type is common,
    and can be encoded in a small space.  The option is used otherwise.
    It is possible that a future option will influence routing, and thus
    the Option will be an extension of the RD as well.  The RD, however,
    is rich enough that this is unlikely.

   6.  Generalized Routing Directive.  Because the Routing Directive is
       so general, it is more likely that we can evolve routing and
       addressing semantics without having to redefine the Pip header or
       the forwarding machinery.

   7.  Host version number.  This number tells what Pip functions a host
       has, such as which PCMP messages it can handle, so that routers
       can respond appropriately to a Pip packet received from a remote
       host.  This supports the capability for routers to evolve ahead of
       hosts.  (All Pip hosts will at least be able to handle all Pip
       near-term architecture functions.)

    The Host version number is also used by the Pip Header Server to
    determine the extent to which the Pip Header Server needs to format
    a header on behalf of the host.

   8.  Generalized Route Types.  The IDRP/MLPV routing algorithm is
       generic with regards to the types of routes it can calculate.
       Thus, adding new route types is a matter of configuring routers to
       accept the new route type, defining metrics for the new route
       type, and defining criteria for selecting one route of the new
       type over another.





Francis                                                        [Page 48]

RFC 1621               Pip Near-term Architecture               May 1994


   Note that none of these evolution features of Pip significantly slow
   down Pip header processing (as compared to other internet protocols).

16.1 Handling Directive (HD) and Routing Context (RC) Evolution

   Because the HD and RC are central to handling and routing of a Pip
   packet, the evolution of these aspects deserves more discussion.

   Both the HD and the RC fields contain multiple parameters.  (In the
   case of the RC, the router treats the RC field as a single number,
   that is, ignores the fact that the RC is composed of multiple
   parameters.  This allows for fast forwarding of Pip packets.) These
   HD and RC multiple parameters may be arranged in any fashion (can be
   any length, subject to the length of the HD and RC fields themselves,
   and can fall on arbitrary bit boundaries).

   Associated with the HD and RC are "Contents" fields that indicate
   what parameters are in the HD and RC fields, and where they are.
   (The Contents fields are basically version numbers, except that a
   higher "version" number is not considered to supersede a lower one.
   Typical types of parameters are address family, TOS value, queueing
   priority, and so on.)

   The Contents field is a single number, the value of which indicates
   the parameter set.  The mapping of Contents field value to parameter
   set is configured manually.

   The procedure for establishing new HD or RC parameter sets (or,
   erasing old ones) is as follows.  Some organization defines the new
   parameter set.  This may involve defining a new parameter.  If it
   does, then the new parameter is described as a Pip Object.  A Pip
   Object is nothing more than a number space used to unambiguously
   identify a new parameter type, and a character string that describes
   it [9].

   Thus, the new parameter set is described as a list of Pip Objects,
   and the bit locations in the HD/RC that each Pip Object occupies.
   The organization that defines the parameter set submits it for an
   official Contents field value.  (It would be submitted to the
   standards body that has authority over Pip, currently the IAB.) If
   the new parameter set is approved, it is given a Contents value, and
   that value is published in a well known place (an RFC).

   Of course, network administrators are free to install or not install
   the new parameter set in their hosts and routers.  In the case of a
   new RC parameter set, installation of the new parameter set does not
   necessarily require any new software, because any Pip routing
   protocol, such as IDRP/MLPV, is able to find routes according to the



Francis                                                        [Page 49]

RFC 1621               Pip Near-term Architecture               May 1994


   new parameter set by appropriate configuration of routers.

   In the case of a new HD parameter set, however, new software is
   necessary--to execute the new handling.

   For new HD and RC parameters sets, systems that do not understand the
   new parameter set can still be configured to execute one of several
   default actions on the new parameter.  These default action allow for
   some control over how new functions are introduced into Pip systems.
   The default actions are:

   1.  Ignore the unknown parameter,

   2.  Set unknown parameter to all 0's,

   3.  Set unknown parameter to all 1's,

   4.  Silently discard packet,

   5.  Discard packet with PCMP Parameter Unknown.

   Action 1 is used when it doesn't much matter if previous systems on a
   path have acted on the parameter or not.  Actions 2 and 3 are used
   when systems should know whether a previous system has not understood
   the parameter.  Actions 4 and 5 are used when something bad happens
   if not all systems understand the new parameter.

16.1.1  Options Evolution

   The evolution of Options is very similar to that of the HD and RC.
   Associated with the Options is an Options Present field that
   indicates in a single word which of up to 8 options are present in
   the Options Part.  There is a Contents field associated with the
   Options Present field that indicates which subset of all possible
   options the Options Present field refers to.  Contents field values
   are assigned in the same way as for the HD and RC Contents fields.

   The same 5 default actions used for the HD and RC also apply to the
   Options.












Francis                                                        [Page 50]

RFC 1621               Pip Near-term Architecture               May 1994


References

   [1]  Thomson, F., "Use of DNS with Pip", Work in Progress.
   [2]  Francis, P., "Pip Header Processing", Work in Progress.
   [3]  Pip Address Assignment Specification,  Work in Progress.
   [4]  Francis, P., "Pip Identifiers", Work in Progress.
   [5]  Pip Assigned Numbers, Work in Progress.
   [6]  Pip Header Protocol,  Work in Progress.
   [7]  Francis, G., "PCMP: Pip Control Message Protocol",
        Work in Progress.
   [8]  Pip Router Discovery Protocol, Work in Progress.
   [9]  Pip Objects Specification, Work in Progress.
   [10] Rajagopolan, and P. Francis, "The Multi-Level Path Vector
        Routing Scheme", Work in Progress.
   [11] Francis, P., "Pip Address Conventions", Work in Progress.
   [12] Francis, P., "On the Assignment of Provider Rooted Addresses",
        Work in Progress.
   [13] Ballardie, Francis, P., and J. Crowcroft, "Core Based Trees
        (CBT), An Architecture for Scalable Inter-Domain Multicast
        Routing", Work in Progress.
   [14] Franics, P., "Pip Host Operation", Work in Progress.
   [15] Egevang, K., and P. Francis, "The IP Network Address
        Translator (NAT)", RFC 1631, Cray Communications, NTT,
        May 1994.

Notes on the References:

   As of the publication of this RFC, a version of [12], titled
   "Comparison of Geographic and Provider-rooted Internet Addressing,"
   was submitted to ISOC INET 94 in Prague.  Reference [13] was
   published at ACM SIGCOMM 93 in San Francisco under the title "An
   Architecture for Scalable Inter-Domain Multicast Routing".

Security Considerations

   Security issues are not discussed in this memo.

Author's Address:

   Paul Francis
   NTT Software Lab
   3-9-11 Midori-cho Musashino-shi
   Tokyo 180 Japan

   Phone: +81-422-59-3843
   Fax +81-422-59-3765
   EMail: francis@cactus.ntt.jp




Francis                                                        [Page 51]