File: rfc2332.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 (2915 lines) | stat: -rw-r--r-- 126,978 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915






Network Working Group                                         J. Luciani
Request for Comments: 2332                                  Bay Networks
Category: Standards Track                                        D. Katz
                                                           cisco Systems
                                                           D. Piscitello
                                                   Core Competence, Inc.
                                                                 B. Cole
                                                        Juniper Networks
                                                            N. Doraswamy
                                                            Bay Networks
                                                              April 1998


                NBMA Next Hop Resolution Protocol (NHRP)

Status of this Memo

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

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document describes the NBMA Next Hop Resolution Protocol (NHRP).
   NHRP can be used by a source station (host or router) connected to a
   Non-Broadcast, Multi-Access (NBMA) subnetwork to determine the
   internetworking layer address and NBMA subnetwork addresses of the
   "NBMA next hop" towards a destination station.  If the destination is
   connected to the NBMA subnetwork, then the NBMA next hop is the
   destination station itself.  Otherwise, the NBMA next hop is the
   egress router from the NBMA subnetwork that is "nearest" to the
   destination station.  NHRP is intended for use in a multiprotocol
   internetworking layer environment over NBMA subnetworks.

   Note that while this protocol was developed for use with NBMA
   subnetworks, it is possible, if not likely, that it will be applied
   to BMA subnetworks as well.  However, this usage of NHRP is for
   further study.

   This document is intended to be a functional superset of the NBMA
   Address Resolution Protocol (NARP) documented in [1].




Luciani, et. al.            Standards Track                     [Page 1]

RFC 2332                       NBMA NHRP                      April 1998


   Operation of NHRP as a means of establishing a transit path across an
   NBMA subnetwork between two routers will be addressed in a separate
   document (see [13]).

1. Introduction

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [15].

   The NBMA Next Hop Resolution Protocol (NHRP) allows a source station
   (a host or router), wishing to communicate over a Non-Broadcast,
   Multi-Access (NBMA) subnetwork, to determine the internetworking
   layer addresses and NBMA addresses of suitable "NBMA next hops"
   toward a destination station.  A subnetwork can be non-broadcast
   either because it technically doesn't support broadcasting (e.g., an
   X.25 subnetwork) or because broadcasting is not feasible for one
   reason or another (e.g., an SMDS multicast group or an extended
   Ethernet would be too large).  If the destination is connected to the
   NBMA subnetwork, then the NBMA next hop is the destination station
   itself.  Otherwise, the NBMA next hop is the egress router from the
   NBMA subnetwork that is "nearest" to the destination station.

   One way to model an NBMA network is by using the notion of logically
   independent IP subnets (LISs). LISs, as defined in [3] and [4], have
   the following properties:

      1)  All members of a LIS have the same IP network/subnet number
          and address mask.

      2)  All members of a LIS are directly connected to the same
          NBMA subnetwork.

      3)  All hosts and routers outside of the LIS are accessed via
          a router.

      4)  All members of a LIS access each other directly (without
          routers).

   Address resolution as described in [3] and [4] only resolves the next
   hop address if the destination station is a member of the same LIS as
   the source station; otherwise, the source station must forward
   packets to a router that is a member of multiple LIS's.  In multi-LIS








Luciani, et. al.            Standards Track                     [Page 2]

RFC 2332                       NBMA NHRP                      April 1998


   configurations, hop-by-hop address resolution may not be sufficient
   to resolve the "NBMA next hop" toward the destination station, and IP
   packets may have multiple IP hops through the NBMA subnetwork.

   Another way to model NBMA is by using the notion of Local Address
   Groups (LAGs) [10]. The essential difference between the LIS and the
   LAG models is that while with the LIS model the outcome of the
   "local/remote" forwarding decision is driven purely by addressing
   information, with the LAG model the outcome of this decision is
   decoupled from the addressing information and is coupled with the
   Quality of Service and/or traffic characteristics.  With the LAG
   model any two entities on a common NBMA network could establish a
   direct communication with each other, irrespective of the entities'
   addresses.

   Support for the LAG model assumes the existence of a mechanism that
   allows any entity (i.e., host or router) connected to an NBMA network
   to resolve an internetworking layer address to an NBMA address for
   any other entity connected to the same NBMA network.  This resolution
   would take place regardless of the address assignments to these
   entities. Within the parameters described in this document, NHRP
   describes such a mechanism.  For example, when the internetworking
   layer address is of type IP, once the NBMA next hop has been
   resolved, the source may either start sending IP packets to the
   destination (in a connectionless NBMA subnetwork such as SMDS) or may
   first establish a connection to the destination with the desired
   bandwidth (in a connection-oriented NBMA subnetwork such as ATM).

   Use of NHRP may be sufficient for hosts doing address resolution when
   those hosts are directly connected to an NBMA subnetwork, allowing
   for straightforward implementations in NBMA stations. NHRP also has
   the capability of determining the egress point from an NBMA
   subnetwork when the destination is not directly connected to the NBMA
   subnetwork and the identity of the egress router is not learned by
   other methods (such as routing protocols).  Optional extensions to
   NHRP provide additional robustness and diagnosability.

   Address resolution techniques such as those described in [3] and [4]
   may be in use when NHRP is deployed.  ARP servers and services over
   NBMA subnetworks may be required to support hosts that are not
   capable of dealing with any model for communication other than the
   LIS model, and deployed hosts may not implement NHRP but may continue
   to support ARP variants such as those described in [3] and [4].  NHRP
   is intended to reduce or eliminate the extra router hops required by
   the LIS model, and can be deployed in a non-interfering manner with
   existing ARP services [14].





Luciani, et. al.            Standards Track                     [Page 3]

RFC 2332                       NBMA NHRP                      April 1998


   The operation of NHRP to establish transit paths across NBMA
   subnetworks between two routers requires additional mechanisms to
   avoid stable routing loops, and will be described in a separate
   document (see [13]).

2. Overview

2.1 Terminology

   The term "network" is highly overloaded, and is especially confusing
   in the context of NHRP.  We use the following terms:

     Internetwork layer--the media-independent layer (IP in the case of
     TCP/IP networks).

     Subnetwork layer--the media-dependent layer underlying the
     internetwork layer, including the NBMA technology (ATM, X.25, SMDS,
     etc.)

     The term "server", unless explicitly stated to the contrary, refers
     to a Next Hop Server (NHS).  An NHS is an entity performing the
     Next Hop Resolution Protocol service within the NBMA cloud.  An NHS
     is always tightly coupled with a routing entity (router, route
     server or edge device) although the converse is not yet guaranteed
     until ubiquitous deployment of this functionality occurs.  Note
     that the presence of intermediate routers that are not coupled with
     an NHS entity may preclude the use of NHRP when source and
     destination stations on different sides of such routers and thus
     such routers may partition NHRP reachability within an NBMA
     network.

     The term "client", unless explicitly stated to the contrary, refers
     to a Next Hop Resolution Protocol client (NHC).  An NHC is an
     entity which initiates NHRP requests of various types in order to
     obtain access to the NHRP service.

     The term "station" generally refers to a host or router which
     contains an NHRP entity.  Occasionally, the term station will
     describe a "user" of the NHRP client or service functionality; the
     difference in usage is largely semantic.

2.2 Protocol Overview

   In this section, we briefly describe how a source S (which
   potentially can be either a router or a host) uses NHRP to determine
   the "NBMA next hop" to destination D.





Luciani, et. al.            Standards Track                     [Page 4]

RFC 2332                       NBMA NHRP                      April 1998


   For administrative and policy reasons, a physical NBMA subnetwork may
   be partitioned into several, disjoint "Logical NBMA subnetworks".  A
   Logical NBMA subnetwork is defined as a collection of hosts and
   routers that share unfiltered subnetwork connectivity over an NBMA
   subnetwork.  "Unfiltered subnetwork connectivity" refers to the
   absence of closed user groups, address screening or similar features
   that may be used to prevent direct communication between stations
   connected to the same NBMA subnetwork.  (Hereafter, unless otherwise
   specified, we use the term "NBMA subnetwork" to mean *logical* NBMA
   subnetwork.)

   Placed within the NBMA subnetwork are one or more entities that
   implement the NHRP protocol.  Such stations which are capable of
   answering NHRP Resolution Requests are known as "Next Hop Servers"
   (NHSs).  Each NHS serves a set of destination hosts, which may or may
   not be directly connected to the NBMA subnetwork.  NHSs cooperatively
   resolve the NBMA next hop within their logical NBMA subnetwork.  In
   addition to NHRP, NHSs may support "classical" ARP service; however,
   this will be the subject of a separate document [14].

   An NHS maintains a cache which contains protocol layer address to
   NBMA subnetwork layer address resolution information.  This cache can
   be constructed from information obtained from NHRP Register packets
   (see Section 5.2.3 and 5.2.4), from NHRP Resolution Request/Reply
   packets, or through mechanisms outside the scope of this document
   (examples of such mechanisms might include ARP[3] and pre-configured
   tables).  Section 6.2 further describes cache management issues.

   For a station within a given LIS to avoid providing NHS
   functionality, there must be one or more NHSs within the NBMA
   subnetwork which are providing authoritative address resolution
   information on its behalf.  Such an NHS is said to be "serving" the
   station.  A station on a LIS that lacks NHS functionality and is a
   client of the NHRP service is known as NHRP Client or just NHCs.  If
   a serving NHS is to be able to supply the address resolution
   information for an NHC then NHSs must exist at each hop along all
   routed paths between the NHC making the resolution request and the
   destination NHC.  The last NHRP entity along the routed path is the
   serving NHS; that is, NHRP Resolution Requests are not forwarded to
   destination NHCs but rather are processed by the serving NHS.

   An NHC also maintains a cache of protocol address to NBMA address
   resolution information.  This cache is populated through information
   obtained from NHRP Resolution Reply packets, from manual
   configuration, or through mechanisms outside the scope of this
   document.





Luciani, et. al.            Standards Track                     [Page 5]

RFC 2332                       NBMA NHRP                      April 1998


   The protocol proceeds as follows.  An event occurs triggering station
   S to want to resolve the NBMA address of a path to D.  This is most
   likely to be when a data packet addressed to station D is to be
   emitted from station S (either because station S is a host, or
   station S is a transit router), but the address resolution could also
   be triggered by other means (a routing protocol update packet, for
   example). Station S first determines the next hop to station D
   through normal routing processes (for a host, the next hop may simply
   be the default router; for routers, this is the "next hop" to the
   destination internetwork layer address).  If the destination's
   address resolution information is already available in S's cache then
   that information is used to forward the packet.  Otherwise, if the
   next hop is reachable through one of its NBMA interfaces, S
   constructs an NHRP Resolution Request packet (see Section 5.2.1)
   containing station D's internetwork layer address as the (target)
   destination address, S's own internetwork layer address as the source
   address (Next Hop Resolution Request initiator), and station S's NBMA
   addressing information.  Station S may also indicate that it prefers
   an authoritative NHRP Resolution Reply (i.e., station S only wishes
   to receive an NHRP Resolution Reply from an NHS serving the
   destination NHC). Station S emits the NHRP Resolution Request packet
   towards the destination.

   If the NHRP Resolution Request is triggered by a data packet then S
   may, while awaiting an NHRP Resolution Reply, choose to dispose of
   the data packet in one of the following ways:

     (a)  Drop the packet
     (b)  Retain the packet until the NHRP Resolution Reply arrives
          and a more optimal path is available
     (c)  Forward the packet along the routed path toward D

   The choice of which of the above to perform is a local policy matter,
   though option (c) is the recommended default, since it may allow data
   to flow to the destination while the NBMA address is being resolved.
   Note that an NHRP Resolution Request for a given destination MUST NOT
   be triggered on every packet.

   When the NHS receives an NHRP Resolution Request, a check is made to
   see if it serves station D.  If the NHS does not serve D, the NHS
   forwards the NHRP Resolution Request to another NHS.  Mechanisms for
   determining how to forward the NHRP Resolution Request are discussed
   in Section 3.

   If this NHS serves D, the NHS resolves station D's NBMA address
   information, and generates a positive NHRP Resolution Reply on D's
   behalf.  NHRP Resolution Replies in this scenario are always marked
   as "authoritative".  The NHRP Resolution Reply packet contains the



Luciani, et. al.            Standards Track                     [Page 6]

RFC 2332                       NBMA NHRP                      April 1998


   address resolution information for station D which is to be sent back
   to S.  Note that if station D is not on the NBMA subnetwork, the next
   hop internetwork layer address will be that of the egress router
   through which packets for station D are forwarded.

   A transit NHS receiving an NHRP Resolution Reply may cache the
   address resolution information contained therein.  To a subsequent
   NHRP Resolution Request, this NHS may respond with the cached, "non-
   authoritative" address resolution information if the NHS is permitted
   to do so (see Sections 5.2.2 and 6.2 for more information on non-
   authoritative versus authoritative NHRP Resolution Replies).  Non-
   authoritative NHRP Resolution Replies are distinguished from
   authoritative NHRP Resolution Replies so that if a communication
   attempt based on non-authoritative information fails, a source
   station can choose to send an authoritative NHRP Resolution Request.
   NHSs MUST NOT respond to authoritative NHRP Resolution Requests with
   cached information.

   If the determination is made that no NHS in the NBMA subnetwork can
   reply to the NHRP Resolution Request for D then a negative NHRP
   Resolution Reply (NAK) is returned.  This occurs when (a) no next-hop
   resolution information is available for station D from any NHS, or
   (b) an NHS is unable to forward the NHRP Resolution Request (e.g.,
   connectivity is lost).

   NHRP Registration Requests, NHRP Purge Requests, NHRP Purge Replies,
   and NHRP Error Indications follow a routed path in the same fashion
   that NHRP Resolution Requests and NHRP Resolution Replies do.
   Specifically, "requests" and "indications" follow the routed path
   from Source Protocol Address (which is the address of the station
   initiating the communication) to the Destination Protocol Address.
   "Replies", on the other hand, follow the routed path from the
   Destination Protocol Address back to the Source Protocol Address with
   the following exceptions: in the case of a NHRP Registration Reply
   and in the case of an NHC initiated NHRP Purge Request, the packet is
   always returned via a direct VC (see Sections 5.2.4 and 5.2.5); if
   one does not exists then one MUST be created.

   NHRP Requests and NHRP Replies do NOT cross the borders of a NBMA
   subnetwork however further study is being done in this area (see
   Section 7).   Thus, the internetwork layer data traffic out of and
   into an NBMA subnetwork always traverses an internetwork layer router
   at its border.

   NHRP optionally provides a mechanism to send a NHRP Resolution Reply
   which contains aggregated address resolution information. For
   example, suppose that router X is the next hop from station S to
   station D and that X is an egress router for all stations sharing an



Luciani, et. al.            Standards Track                     [Page 7]

RFC 2332                       NBMA NHRP                      April 1998


   internetwork layer address prefix with station D.  When an NHRP
   Resolution Reply is generated in response to a NHRP Resolution
   Request, the responder may augment the internetwork layer address of
   station D with a prefix length (see Section 5.2.0.1).  A subsequent
   (non-authoritative) NHRP Resolution Request for some destination that
   shares an internetwork layer address prefix (for the number of bits
   specified in the prefix length) with D may be satisfied with this
   cached information.  See section 6.2 regarding caching issues.

   To dynamically detect subnetwork-layer filtering in NBMA subnetworks
   (e.g., X.25 closed user group facility, or SMDS address screens), to
   trace the routed path that an NHRP packet takes, or to provide loop
   detection and diagnostic capabilities, a "Route Record" may be
   included in NHRP packets (see Sections 5.3.2 and 5.3.3).  The Route
   Record extensions are the NHRP Forward Transit NHS Record Extension
   and the NHRP Reverse Transit NHS Record Extension.  They contain the
   internetwork (and subnetwork layer) addresses of all intermediate
   NHSs between source and destination and between destination and
   source respectively.  When a source station is unable to communicate
   with the responder (e.g., an attempt to open an SVC fails), it may
   attempt to do so successively with other subnetwork layer addresses
   in the NHRP Forward Transit NHS Record Extension until it succeeds
   (if authentication policy permits such action).  This approach can
   find a suitable egress point in the presence of subnetwork-layer
   filtering (which may be source/destination sensitive, for instance,
   without necessarily creating separate logical NBMA subnetworks) or
   subnetwork-layer congestion (especially in connection-oriented
   media).

3. Deployment

   NHRP Resolution Requests traverse one or more hops within an NBMA
   subnetwork before reaching the station that is expected to generate a
   response.  Each station, including the source station, chooses a
   neighboring NHS to which it will forward the NHRP Resolution Request.
   The NHS selection procedure typically involves applying a destination
   protocol layer address to the protocol layer routing table which
   causes a routing decision to be returned.  This routing decision is
   then used to forward the NHRP Resolution Request to the downstream
   NHS. The destination protocol layer address previously mentioned is
   carried within the NHRP Resolution Request packet.  Note that even
   though a protocol layer address was used to acquire a routing
   decision, NHRP packets are not encapsulated within a protocol layer
   header but rather are carried at the NBMA layer using the
   encapsulation described in Section 5.






Luciani, et. al.            Standards Track                     [Page 8]

RFC 2332                       NBMA NHRP                      April 1998


   Each NHS/router examines the NHRP Resolution Request packet on its
   way toward the destination.  Each NHS which the NHRP packet traverses
   on the way to the packet's destination might modify the packet (e.g.,
   updating the Forward Record extension).  Ignoring error situations,
   the NHRP Resolution Request eventually arrives at a station that is
   to generate an NHRP Resolution Reply.  This responding station
   "serves" the destination.  The responding station generates an NHRP
   Resolution Reply using the source protocol address from within the
   NHRP packet to determine where the NHRP Resolution Reply should be
   sent.

   Rather than use routing to determine the next hop for an NHRP packet,
   an NHS may use other applicable means (such as static configuration
   information ) in order to determine to which neighboring NHSs to
   forward the NHRP Resolution Request packet as long as such other
   means would not cause the NHRP packet to arrive at an NHS which is
   not along the routed path.  The use of static configuration
   information for this purpose is beyond the scope of this document.

   The NHS serving a particular destination must lie along the routed
   path to that destination.  In practice, this means that all egress
   routers must double as NHSs serving the destinations beyond them, and
   that hosts on the NBMA subnetwork are served by routers that double
   as NHSs.  Also, this implies that forwarding of NHRP packets within
   an NBMA subnetwork requires a contiguous deployment of NHRP capable
   routers.  It is important that, in a given LIS/LAG which is using
   NHRP, all NHSs within the LIS/LAG have at least some portion of their
   resolution databases synchronized so that a packet arriving at one
   router/NHS in a given LIS/LAG will be forwarded in the same fashion
   as a packet arriving at a different router/NHS for the given LIS/LAG.
   One method, among others, is to use the Server Cache Synchronization
   Protocol (SCSP) [12].  It is RECOMMENDED that SCSP be the method used
   when a LIS/LAG contains two or more router/NHSs.

   During migration to NHRP, it cannot be expected that all routers
   within the NBMA subnetwork are NHRP capable.  Thus, NHRP traffic
   which would otherwise need to be forwarded through such routers can
   be expected to be dropped due to the NHRP packet not being
   recognized.  In this case, NHRP will be unable to establish any
   transit paths whose discovery requires the traversal of the non-NHRP
   speaking routers.  If the client has tried and failed to acquire a
   cut through path then the client should use the network layer routed
   path as a default.

   If an NBMA technology offers a group, an anycast, or a multicast
   addressing feature then the NHC may be configured with such an
   address (appropriate to the routing realm it participates in) which
   would be assigned to all NHS serving that routing realm.  This



Luciani, et. al.            Standards Track                     [Page 9]

RFC 2332                       NBMA NHRP                      April 1998


   address can then be used for establishing an initial connection to an
   NHS to transmit a registration request.  This address may not be used
   for sending NHRP requests.  The resulting VC may be used for NHRP
   requests if and only if the registration response is received over
   that VC, thereby indicating that one happens to have anycast
   connected to an NHS serving the LIS/LAG.  In the case of non-
   connection oriented networks, or of multicast (rather than anycast)
   addresses, the addres MUST NOT be used for sending NHRP resolution
   requests.

   When an NHS "serves" an NHC, the NHS MUST send NHRP messages destined
   for the NHC directly to the NHC.  That is, the NHRP message MUST NOT
   transit through any NHS which is not serving the NHC when the NHRP
   message is currently at an NHS which does serve the NHC (this, of
   course, assumes the NHRP message is destined for the NHC).  Further,
   an NHS which serves an NHC SHOULD have a direct NBMA level connection
   to that NHC (see Section 5.2.3 and 5.2.4 for examples).

   With the exception of NHRP Registration Requests (see Section 5.2.3
   and 5.2.4 for details of the NHRP Registration Request case), an NHC
   MUST send NHRP messages over a direct NBMA level connection between
   the serving NHS and the served NHC.

   It may not be desirable to maintain semi-permanent NBMA level
   connectivity between the NHC and the NHS.   In this case, when NBMA
   level connectivity is initially setup between the NHS and the NHC (as
   described in Section 5.2.4), the NBMA address of the NHS should be
   obtained through the NBMA level signaling technology.  This address
   should be stored for future use in setting up subsequent NBMA level
   connections.  A somewhat more information rich technique to obtain
   the address information (and more) of the serving NHS would be for
   the NHC to include the Responder Address extension (see Section
   5.3.1) in the NHRP Registration Request and to store the information
   returned to the NHC in the Responder Address extension which is
   subsequently included in the NHRP Registration Reply.  Note also
   that, in practice, a client's default router should also be its NHS;
   thus a client may be able to know the NBMA address of its NHS from
   the configuration which was already required for the client to be
   able to communicate.  Further, as mentioned in Section 4, NHCs may be
   configured with the addressing information of one or more NHSs.

4. Configuration

   Next Hop Clients

     An NHC connected to an NBMA subnetwork MAY be configured with the
     Protocol address(es) and NBMA address(es) of its NHS(s).  The
     NHS(s) will likely also represent the NHC's default or peer



Luciani, et. al.            Standards Track                    [Page 10]

RFC 2332                       NBMA NHRP                      April 1998


     routers, so their NBMA addresses may be obtained from the NHC's
     existing configuration.  If the NHC is attached to several
     subnetworks (including logical NBMA subnetworks), the NHC should
     also be configured to receive routing information from its NHS(s)
     and peer routers so that it can determine which internetwork layer
     networks are reachable through which subnetworks.

   Next Hop Servers

     An NHS is configured with knowledge of its own internetwork layer
     and NBMA addresses.  An NHS MAY also be configured with a set of
     internetwork layer address prefixes that correspond to the
     internetwork layer addresses of the stations it serves. The NBMA
     addresses of the stations served by the NHS may be learned via NHRP
     Registration packets.

     If a served NHC is attached to several subnetworks, the
     router/route-server coresident with the serving NHS may also need
     to be configured to advertise routing information to such NHCs.

     If an NHS acts as an egress router for stations connected to other
     subnetworks than the NBMA subnetwork, the NHS must, in addition to
     the above, be configured to exchange routing information between
     the NBMA subnetwork and these other subnetworks.

     In all cases, routing information is exchanged using conventional
     intra-domain and/or inter-domain routing protocols.

5. NHRP Packet Formats

   This section describes the format of NHRP packets.  In the following,
   unless otherwise stated explicitly, the unqualified term "request"
   refers generically to any of the NHRP packet types which are
   "requests".  Further, unless otherwise stated explicitly, the
   unqualified term "reply" refers generically to any of the NHRP packet
   types which are "replies".

   An NHRP packet consists of a Fixed Part, a Mandatory Part, and an
   Extensions Part.  The Fixed Part is common to all NHRP packet types.
   The Mandatory Part MUST be present, but varies depending on packet
   type.  The Extensions Part also varies depending on packet type, and
   need not be present.

   The length of the Fixed Part is fixed at 20 octets.  The length of
   the Mandatory Part is determined by the contents of the extensions
   offset field (ar$extoff).  If ar$extoff=0x0 then the mandatory part
   length is equal to total packet length (ar$pktsz) minus 20 otherwise
   the mandatory part length is equal to ar$extoff minus 20.  The length



Luciani, et. al.            Standards Track                    [Page 11]

RFC 2332                       NBMA NHRP                      April 1998


   of the Extensions Part is implied by ar$pktsz minus ar$extoff.  NHSs
   may increase the size of an NHRP packet as a result of extension
   processing, but not beyond the offered maximum packet size of the
   NBMA network.

   NHRP packets are actually members of a wider class of address mapping
   and management protocols being developed by the IETF. A specific
   encapsulation, based on the native formats used on the particular
   NBMA network over which NHRP is carried, indicates the generic IETF
   mapping and management protocol. For example, SMDS networks always
   use LLC/SNAP encapsulation at the NBMA layer [4], and an NHRP packet
   is preceded by the following LLC/SNAP encapsulation:

   [0xAA-AA-03] [0x00-00-5E] [0x00-03]

   The first three octets are LLC, indicating that SNAP follows.  The
   SNAP OUI portion is the IANA's OUI, and the SNAP PID portion
   identifies the mapping and management protocol. A field in the Fixed
   Header following the encapsulation indicates that it is NHRP.

   ATM uses either LLC/SNAP encapsulation of each packet (including
   NHRP), or uses no encapsulation on VCs dedicated to a single protocol
   (see [7]).  Frame Relay and X.25 both use NLPID/SNAP encapsulation or
   identification of NHRP, using a NLPID of 0x0080 and the same SNAP
   contents as above (see [8], [9]).

   Fields marked "unused" MUST be set to zero on transmission, and
   ignored on receipt.

   Most packet types (ar$op.type) have both internetwork layer
   protocol-independent fields and protocol-specific fields. The
   protocol type/snap fields (ar$pro.type/snap) qualify the format of
   the protocol-specific fields.

5.1 NHRP Fixed Header

   The Fixed Part of the NHRP packet contains those elements of the NHRP
   packet which are always present and do not vary in size with the type
   of packet.












Luciani, et. al.            Standards Track                    [Page 12]

RFC 2332                       NBMA NHRP                      April 1998



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            ar$afn             |          ar$pro.type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          ar$pro.snap                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  ar$pro.snap  |   ar$hopcnt   |            ar$pktsz           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           ar$chksum           |            ar$extoff          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ar$op.version |   ar$op.type  |    ar$shtl    |    ar$sstl    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   ar$afn
     Defines the type of "link layer" addresses being carried.  This
     number is taken from the 'address family number' list specified in
     [6].  This field has implications to the coding of ar$shtl and
     ar$sstl as described below.

   ar$pro.type
     field is a 16 bit unsigned integer representing the following
     number space:

       0x0000 to 0x00FF  Protocols defined by the equivalent NLPIDs.
       0x0100 to 0x03FF  Reserved for future use by the IETF.
       0x0400 to 0x04FF  Allocated for use by the ATM Forum.
       0x0500 to 0x05FF  Experimental/Local use.
       0x0600 to 0xFFFF  Protocols defined by the equivalent Ethertypes.

     (based on the observations that valid Ethertypes are never smaller
     than 0x600, and NLPIDs never larger than 0xFF.)

   ar$pro.snap
     When ar$pro.type has a value of 0x0080, a SNAP encoded extension is
     being used to encode the protocol type. This snap extension is
     placed in the ar$pro.snap field.  This is termed the 'long form'
     protocol ID. If ar$pro != 0x0080 then the ar$pro.snap field MUST be
     zero on transmit and ignored on receive. The ar$pro.type field
     itself identifies the protocol being referred to. This is termed
     the 'short form' protocol ID.

     In all cases, where a protocol has an assigned number in the
     ar$pro.type space (excluding 0x0080) the short form MUST be used
     when transmitting NHRP messages; i.e., if Ethertype or NLPID
     codings exist then they are used on transmit rather than the



Luciani, et. al.            Standards Track                    [Page 13]

RFC 2332                       NBMA NHRP                      April 1998


     ethertype.   If both Ethertype and NLPID codings exist then when
     transmitting NHRP messages, the Ethertype coding MUST be used (this
     is consistent with RFC 1483 coding).  So, for example, the
     following codings exist for IP:

       SNAP:      ar$pro.type = 0x00-80, ar$pro.snap = 0x00-00-00-08-00
       NLPID:     ar$pro.type = 0x00-CC, ar$pro.snap = 0x00-00-00-00-00
       Ethertype: ar$pro.type = 0x08-00, ar$pro.snap = 0x00-00-00-00-00

     and thus, since the Ethertype coding exists, it is used in
     preference.

   ar$hopcnt
     The Hop count indicates the maximum number of NHSs that an NHRP
     packet is allowed to traverse before being discarded.  This field
     is used in a similar fashion to the way that a TTL is used in an IP
     packet and should be set accordingly.  Each NHS decrements the TTL
     as the NHRP packet transits the NHS on the way to the next hop
     along the routed path to the destination.  If an NHS receives an
     NHRP packet which it would normally forward to a next hop and that
     packet contains an ar$hopcnt set to zero then the NHS sends an
     error indication message back to the source protocol address
     stating that the hop count has been exceeded (see Section 5.2.7)
     and the NHS drops the packet in error;  however, an error
     indication is never sent as a result of receiving an error
     indication.  When a responding NHS replies to an NHRP request, that
     NHS places a value in ar$hopcnt as if it were sending a request of
     its own.

   ar$pktsz
     The total length of the NHRP packet, in octets (excluding link
     layer encapsulation).

   ar$chksum
     The standard IP checksum over the entire NHRP packet starting at
     the fixed header.  If the packet is an odd number of bytes in
     length then this calculation is performed as if a byte set to 0x00
     is appended to the end of the packet.

   ar$extoff
     This field identifies the existence and location of NHRP
     extensions.  If this field is 0 then no extensions exist otherwise
     this field represents the offset from the beginning of the NHRP
     packet (i.e., starting from the ar$afn field) of the first
     extension.






Luciani, et. al.            Standards Track                    [Page 14]

RFC 2332                       NBMA NHRP                      April 1998


   ar$op.version
     This field indicates what version of generic address mapping and
     management protocol is represented by this message.

       0               MARS protocol [11].
       1               NHRP as defined in this document.
       0x02 - 0xEF     Reserved for future use by the IETF.
       0xF0 - 0xFE     Allocated for use by the ATM Forum.
       0xFF            Experimental/Local use.

   ar$op.type
     When ar$op.version == 1, this is the NHRP packet type: NHRP
     Resolution Request(1), NHRP Resolution Reply(2), NHRP Registration
     Request(3), NHRP Registration Reply(4), NHRP Purge Request(5), NHRP
     Purge Reply(6), or NHRP Error Indication(7).  Use of NHRP packet
     Types in the range 128 to 255 are reserved for research or use in
     other protocol development and will be administered by IANA as
     described in Section 9.

   ar$shtl
     Type & length of source NBMA address interpreted in the context of
     the 'address family number'[6] indicated by ar$afn.  See below for
     more details.

   ar$sstl
     Type & length of source NBMA subaddress interpreted in the context
     of the 'address family number'[6] indicated by ar$afn.  When an
     NBMA technology has no concept of a subaddress, the subaddress
     length is always coded ar$sstl = 0 and no storage is allocated for
     the subaddress in the appropriate mandatory part.  See below for
     more details.

   Subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
   T/L) and subnetwork layer subaddresses type/length fields (e.g.,
   ar$sstl, Cli SAddr T/L) are coded as follows:

    7 6 5 4 3 2 1 0
   +-+-+-+-+-+-+-+-+
   |0|x|  length   |
   +-+-+-+-+-+-+-+-+

   The most significant bit is reserved and MUST be set to zero. The
   second most significant bit (x) is a flag indicating whether the
   address being referred to is in:

      - NSAP format (x = 0).
      - Native E.164 format (x = 1).




Luciani, et. al.            Standards Track                    [Page 15]

RFC 2332                       NBMA NHRP                      April 1998


   For NBMA technologies that use neither NSAP nor E.164 format
   addresses, x = 0 SHALL be used to indicate the native form for the
   particular NBMA technology.

   If the NBMA network is ATM and a subaddress (e.g., Source NBMA
   SubAddress, Client NBMA SubAddress) is to be included in any part of
   the NHRP packet then ar$afn MUST be set to 0x000F; further, the
   subnetwork layer address type/length fields (e.g., ar$shtl, Cli Addr
   T/L) and subnetwork layer subaddress type/length fields (e.g.,
   ar$sstl, Cli SAddr T/L) MUST be coded as in [11].  If the NBMA
   network is ATM and no subaddress field is to be included in any part
   of the NHRP packet then ar$afn MAY be set to 0x0003 (NSAP) or 0x0008
   (E.164) accordingly.

   The bottom 6 bits is an unsigned integer value indicating the length
   of the associated NBMA address in octets. If this value is zero the
   flag x is ignored.

5.2.0 Mandatory Part

   The Mandatory Part of the NHRP packet contains the operation specific
   information (e.g., NHRP Resolution Request/Reply, etc.) and variable
   length data which is pertinent to the packet type.

5.2.0.1 Mandatory Part Format

   Sections 5.2.1 through 5.2.6 have a very similar mandatory part.
   This mandatory part includes a common header and zero or more Client
   Information Entries (CIEs). Section 5.2.7 has a different format
   which is specified in that section.

   The common header looks like the following:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Proto Len | Dst Proto Len |           Flags               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request ID                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source NBMA Subaddress (variable length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Destination  Protocol Address (variable length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Luciani, et. al.            Standards Track                    [Page 16]

RFC 2332                       NBMA NHRP                      April 1998


   And the CIEs have the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code       | Prefix Length |         unused                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Transmission Unit    |        Holding Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Client NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Client NBMA Subaddress (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Client Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        .....................
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Code       | Prefix Length |         unused                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Transmission Unit    |        Holding Time           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Cli Addr T/L | Cli SAddr T/L | Cli Proto Len |  Preference   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Client NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Client NBMA Subaddress (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Client Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meanings of the fields are as follows:

   Src Proto Len
     This field holds the length in octets of the Source Protocol
     Address.

   Dst Proto Len
     This field holds the length in octets of the Destination Protocol
     Address.

   Flags
     These flags are specific to the given message type and they are
     explained in each section.






Luciani, et. al.            Standards Track                    [Page 17]

RFC 2332                       NBMA NHRP                      April 1998


   Request ID
     A value which, when coupled with the address of the source,
     provides a unique identifier for the information contained in a
     "request" packet.  This value is copied directly from an "request"
     packet into the associated "reply".  When a sender of a "request"
     receives "reply", it will compare the Request ID and source address
     information in the received "reply" against that found in its
     outstanding "request" list.  When a match is found then the
     "request" is considered to be acknowledged.

     The value is taken from a 32 bit counter that is incremented each
     time a new "request" is transmitted.  The same value MUST be used
     when resending a "request", i.e., when a "reply" has not been
     received for a "request" and a retry is sent after an appropriate
     interval.

     It is RECOMMENDED that the initial value for this number be 0.  A
     node MAY reuse a sequence number if and only if the reuse of the
     sequence number is not precluded by use of a particular method of
     synchronization (e.g., as described in Appendix A).

   The NBMA address/subaddress form specified below allows combined
   E.164/NSAPA form of NBMA addressing. For NBMA technologies without a
   subaddress concept, the subaddress field is always ZERO length and
   ar$sstl = 0.

   Source NBMA Address
     The Source NBMA address field is the address of the source station
     which is sending the "request". If the field's length as specified
     in ar$shtl is 0 then no storage is allocated for this address at
     all.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the source
     station which is sending the "request".  If the field's length as
     specified in ar$sstl is 0 then no storage is allocated for this
     address at all.

   For those NBMA technologies which have a notion of "Calling Party
   Addresses", the Source NBMA Addresses above are the addresses used
   when signaling for an SVC.

   "Requests" and "indications" follow the routed path from Source
   Protocol Address to the Destination Protocol Address. "Replies", on
   the other hand, follow the routed path from the Destination Protocol
   Address back to the Source Protocol Address with the following





Luciani, et. al.            Standards Track                    [Page 18]

RFC 2332                       NBMA NHRP                      April 1998


   exceptions: in the case of a NHRP Registration Reply and in the case
   of an NHC initiated NHRP Purge Request, the packet is always returned
   via a direct VC (see Sections 5.2.4 and 5.2.5).

   Source Protocol Address
     This is the protocol address of the station which is sending the
     "request".  This is also the protocol address of the station toward
     which a "reply" packet is sent.

   Destination Protocol Address
     This is the protocol address of the station toward which a
     "request" packet is sent.

   Code
     This field is message specific.  See the relevant message sections
     below.  In general, this field is a NAK code; i.e., when the field
     is 0 in a reply then the packet is acknowledging a request and if
     it contains any other value the packet contains a negative
     acknowledgment.

   Prefix Length
     This field is message specific.  See the relevant message sections
     below.  In general, however, this fields is used to indicate that
     the information carried in an NHRP message pertains to an
     equivalence class of internetwork layer addresses rather than just
     a single internetwork layer address specified. All internetwork
     layer addresses that match the first "Prefix Length" bit positions
     for the specific internetwork layer address are included in the
     equivalence class.  If this field is set to 0x00 then this field
     MUST be ignored and no equivalence information is assumed (note
     that 0x00 is thus equivalent to 0xFF).

   Maximum Transmission Unit
     This field gives the maximum transmission unit for the relevant
     client station.  If this value is 0 then either the default MTU is
     used or the MTU negotiated via signaling is used if such
     negotiation is possible for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the Next Hop NBMA information specified in the CIE is considered to
     be valid.  Cached information SHALL be discarded when the holding
     time expires.  This field must be set to 0 on a NAK.








Luciani, et. al.            Standards Track                    [Page 19]

RFC 2332                       NBMA NHRP                      April 1998


   Cli Addr T/L
     Type & length of next hop NBMA address specified in the CIE.  This
     field is interpreted in the context of the 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0003 for ATM).

   Cli SAddr T/L
     Type & length of next hop NBMA subaddress specified in the CIE.
     This field is interpreted in the context of the 'address family
     number'[6] indicated by ar$afn (e.g., ar$afn=0x0015 for ATM makes
     the address an E.164 and the subaddress an ATM Forum NSAP address).
     When an NBMA technology has no concept of a subaddress, the
     subaddress is always null with a length of 0.  When the address
     length is specified as 0 no storage is allocated for the address.

   Cli Proto Len
     This field holds the length in octets of the Client Protocol
     Address specified in the CIE.

   Preference
     This field specifies the preference for use of the specific CIE
     relative to other CIEs.  Higher values indicate higher preference.
     Action taken when multiple CIEs have equal or highest preference
     value is a local matter.

   Client NBMA Address
     This is the client's NBMA address.

   Client NBMA SubAddress
     This is the client's NBMA subaddress.

   Client Protocol Address
     This is the client's internetworking layer address specified.

   Note that an NHS may cache source address binding information from an
   NHRP Resolution Request if and only if the conditions described in
   Section 6.2 are met for the NHS.  In all other cases, source address
   binding information appearing in an NHRP message MUST NOT be cached.

5.2.1 NHRP Resolution Request

   The NHRP Resolution Request packet has a Type code of 1. Its
   mandatory part is coded as described in Section 5.2.0.1 and the
   message specific meanings of the fields are as follows:

   Flags - The flags field is coded as follows:






Luciani, et. al.            Standards Track                    [Page 20]

RFC 2332                       NBMA NHRP                      April 1998


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Q|A|D|U|S|       unused        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Q
       Set if the station sending the NHRP Resolution Request is a
       router; clear if the it is a host.

     A
       This bit is set in a NHRP Resolution Request if only
       authoritative next hop information is desired and is clear
       otherwise.  See the NHRP Resolution Reply section below for
       further details on the "A" bit and its usage.

     D
       Unused (clear on transmit)

     U
       This is the Uniqueness bit. This bit aids in duplicate address
       detection.  When this bit is set in an NHRP Resolution Request
       and one or more entries exist in the NHS cache which meet the
       requirements of the NHRP Resolution Request then only the CIE in
       the NHS's cache with this bit set will be returned.  Note that
       even if this bit was set at registration time, there may still be
       multiple CIEs that might fulfill the NHRP Resolution Request
       because an entire subnet can be registered through use of the
       Prefix Length in the CIE and the address of interest might be
       within such a subnet. If the "uniqueness" bit is set and the
       responding NHS has one or more cache entries which match the
       request but no such cache entry has the "uniqueness" bit set,
       then the NHRP Resolution Reply returns with a NAK code of "13 -
       Binding Exists But Is Not Unique" and no CIE is included.  If a
       client wishes  to  receive  non- unique  Next  Hop Entries, then
       the client must have the "uniqueness" bit set to zero in its NHRP
       Resolution Request. Note that when this bit is set in an NHRP
       Registration Request, only a single CIE may be specified in the
       NHRP Registration Request and that CIE must have the Prefix
       Length field set to 0xFF.

     S
       Set if the binding between the Source Protocol Address and the
       Source NBMA information in the NHRP Resolution Request is
       guaranteed to be stable and accurate (e.g., these addresses are
       those of an ingress router which is connected to an ethernet stub
       network or the NHC is an NBMA attached host).




Luciani, et. al.            Standards Track                    [Page 21]

RFC 2332                       NBMA NHRP                      April 1998


   Zero or one CIEs (see Section 5.2.0.1) may be specified in an NHRP
   Resolution Request.  If one is specified then that entry carries the
   pertinent information for the client sourcing the NHRP Resolution
   Request.  Usage of the CIE in the NHRP Resolution Request is
   described below:

     Prefix Length
       If a CIE is specified in the NHRP Resolution Request then the
       Prefix Length field may be used to qualify the widest acceptable
       prefix which may be used to satisfy the NHRP Resolution Request.
       In the case of NHRP Resolution Request/Reply, the Prefix Length
       specifies the equivalence class of addresses which match the
       first "Prefix Length" bit positions of the Destination Protocol
       Address.  If the "U" bit is set in the common header then this
       field MUST be set to 0xFF.

     Maximum Transmission Unit
       This field gives the maximum transmission unit for the source
       station.  A possible use of this field in the NHRP Resolution
       Request packet is for the NHRP Resolution Requester to ask for a
       target MTU.

     Holding Time
       The Holding Time specified in the one CIE permitted to be
       included in an NHRP Resolution Request is the amount of time
       which the source address binding information in the NHRP
       Resolution Request is permitted to cached by transit and
       responding NHSs.  Note that this field may only have a non-zero
       value if the S bit is set.

     All other fields in the CIE MUST be ignored and SHOULD be set to 0.

   The Destination Protocol Address in the common header of the
   Mandatory Part of this message contains the protocol address of the
   station for which resolution is desired.  An NHC MUST send the NHRP
   Resolution Request directly to one of its serving NHSs (see Section 3
   for more information).

5.2.2 NHRP Resolution Reply

   The NHRP Resolution Reply packet has a Type code of 2. CIEs
   correspond to Next Hop Entries in an NHS's cache which match the
   criteria in the NHRP Resolution Request.  Its mandatory part is coded
   as described in Section 5.2.0.1.  The message specific meanings of
   the fields are as follows:

   Flags - The flags field is coded as follows:




Luciani, et. al.            Standards Track                    [Page 22]

RFC 2332                       NBMA NHRP                      April 1998


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Q|A|D|U|S|       unused        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Q
       Copied from the NHRP Resolution Request.  Set if the NHRP
       Resolution Requester is a router;  clear if it is a host.

     A
       Set if the next hop CIE in the NHRP Resolution Reply is
       authoritative; clear if the NHRP Resolution Reply is non-
       authoritative.

       When an NHS receives a NHRP Resolution Request for authoritative
       information for which it is the authoritative source, it MUST
       respond with a NHRP Resolution Reply containing all and only
       those next hop CIEs which are contained in the NHS's cache which
       both match the criteria of the NHRP Resolution Request and are
       authoritative cache entries.  An NHS is an authoritative source
       for a NHRP Resolution Request if the information in the NHS's
       cache matches the NHRP Resolution Request criteria and that
       information was obtained through a NHRP Registration Request or
       through synchronization with an NHS which obtained this
       information through a NHRP Registration Request.  An
       authoritative cache entry is one which is obtained through a NHRP
       Registration Request or through synchronization with an NHS which
       obtained this information through a NHRP Registration Request.

       An NHS obtains non-authoritative CIEs through promiscuous
       listening to NHRP packets other than NHRP Registrations which are
       directed at it.  A NHRP Resolution Request which indicates a
       request for non-authoritative information should cause a NHRP
       Resolution Reply which contains all entries in the replying NHS's
       cache (i.e., both authoritative and non-authoritative) which
       match the criteria specified in the request.

     D
       Set if the association between destination and the associate next
       hop information included in all CIEs of the NHRP Resolution Reply
       is guaranteed to be stable for the lifetime of the information
       (the holding time).  This is the case if the Next Hop protocol
       address in a CIE identifies the destination (though it may be
       different in value than the Destination address if the
       destination system has multiple addresses) or if the destination
       is not connected directly to the NBMA subnetwork but the egress
       router to that destination is guaranteed to be stable (such as



Luciani, et. al.            Standards Track                    [Page 23]

RFC 2332                       NBMA NHRP                      April 1998


       when the destination is immediately adjacent to the egress router
       through a non-NBMA interface).

     U
       This is the Uniqueness bit. See the NHRP Resolution Request
       section above for details.  When this bit is set, only one CIE is
       included since only one unique binding should exist in an NHS's
       cache.

     S
       Copied from NHRP Resolution Request message.

   One or more CIEs are specified in the NHRP Resolution Reply. Each CIE
   contains NHRP next hop information which the responding NHS has
   cached and which matches the parameters specified in the NHRP
   Resolution Request.  If no match is found by the NHS issuing the NHRP
   Resolution Reply then a single CIE is enclosed with the a CIE Code
   set appropriately (see below) and all other fields MUST be ignored
   and SHOULD be set to 0.  In order to facilitate the use of NHRP by
   minimal client implementations, the first CIE MUST contain the next
   hop with the highest preference value so that such an implementation
   need parse only a single CIE.

     Code
       If this field is set to zero then this packet contains a
       positively acknowledged NHRP Resolution Reply.  If this field
       contains any other value then this message contains an NHRP
       Resolution Reply NAK which means that an appropriate
       internetworking layer to NBMA address binding was not available
       in the responding NHS's cache.  If NHRP Resolution Reply contains
       a Client Information Entry with a NAK Code other than 0 then it
       MUST NOT contain any other CIE.  Currently defined NAK Codes are
       as follows:

       4 - Administratively Prohibited

         An NHS may refuse an NHRP Resolution Request attempt for
         administrative reasons (due to policy constraints or routing
         state).  If so, the NHS MUST send an NHRP Resolution Reply
         which contains a NAK code of 4.

       5 - Insufficient Resources

         If an NHS cannot serve a station due to a lack of resources
         (e.g., can't store sufficient information to send a purge if
         routing changes), the NHS MUST reply with a NAKed NHRP
         Resolution Reply which contains a NAK code of 5.




Luciani, et. al.            Standards Track                    [Page 24]

RFC 2332                       NBMA NHRP                      April 1998


       12 - No Internetworking Layer Address to NBMA Address Binding
            Exists

         This code states that there were absolutely no internetworking
         layer address to NBMA address bindings found in the responding
         NHS's cache.

       13 - Binding Exists But Is Not Unique

         This code states that there were one or more internetworking
         layer address to NBMA address bindings found in the responding
         NHS's cache, however none of them had the uniqueness bit set.

     Prefix Length
       In the case of NHRP Resolution Reply, the Prefix Length specifies
       the equivalence class of addresses which match the first "Prefix
       Length" bit positions of the Destination Protocol Address.

     Holding Time
       The Holding Time specified in a CIE of an NHRP Resolution Reply
       is the amount of time remaining before the expiration of the
       client information which is cached at the replying NHS.  It is
       not the value which was registered by the client.

     The remainder of the fields for the CIE for each next hop are
     filled out as they were defined when the next hop was registered
     with the responding NHS (or one of the responding NHS's
     synchronized servers) via the NHRP Registration Request.

   Load-splitting may be performed when more than one Client Information
   Entry is returned to a requester when equal preference values are
   specified.  Also, the alternative addresses may be used in case of
   connectivity failure in the NBMA subnetwork (such as a failed call
   attempt in connection-oriented NBMA subnetworks).

   Any extensions present in the NHRP Resolution Request packet MUST be
   present in the NHRP Resolution Reply even if the extension is non-
   Compulsory.

   If an unsolicited NHRP Resolution Reply packet is received, an Error
   Indication of type Invalid NHRP Resolution Reply Received SHOULD be
   sent in response.

   When an NHS that serves a given NHC receives an NHRP Resolution Reply
   destined for that NHC then the NHS must MUST send the NHRP Resolution
   Reply directly to the NHC (see Section 3).





Luciani, et. al.            Standards Track                    [Page 25]

RFC 2332                       NBMA NHRP                      April 1998


5.2.3 NHRP Registration Request

   The NHRP Registration Request is sent from a station to an NHS to
   notify the NHS of the station's NBMA information.  It has a Type code
   of 3. Each CIE corresponds to Next Hop information which is to be
   cached at an NHS.  The mandatory part of an NHRP Registration Request
   is coded as described in Section 5.2.0.1.  The message specific
   meanings of the fields are as follows:

   Flags - The flags field is coded as follows:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|         unused              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     U
       This is the Uniqueness bit. When set in an NHRP Registration
       Request, this bit indicates that the registration of the protocol
       address is unique within the confines of the set of synchronized
       NHSs.  This "uniqueness" qualifier MUST be stored in the NHS/NHC
       cache.  Any attempt to register a binding between the protocol
       address and an NBMA address when this bit is set MUST be rejected
       with a Code of "14 - Unique Internetworking Layer Address Already
       Registered" if the replying NHS already has a cache entry for the
       protocol address and the cache entry has the "uniqueness" bit
       set.  A registration of a CIE's information is rejected when the
       CIE is returned with the Code field set to anything other than
       0x00.  See the description of the uniqueness bit in NHRP
       Resolution Request section above for further details.  When this
       bit is set only, only one CIE MAY be included in the NHRP
       Registration Request.

   Request ID
     The request ID has the same meaning as described in Section
     5.2.0.1.  However, the request ID for NHRP Registrations which is
     maintained at each client MUST be kept in non-volatile memory so
     that when a client crashes and reregisters there will be no
     inconsistency in the NHS's database.  In order to reduce the
     overhead associated with updating non-volatile memory, the actual
     updating need not be done with every increment of the Request ID
     but could be done, for example, every 50 or 100 increments.  In
     this scenario, when a client crashes and reregisters it knows to
     add 100 to the value of the Request ID in the non-volatile memory
     before using the Request ID for subsequent registrations.





Luciani, et. al.            Standards Track                    [Page 26]

RFC 2332                       NBMA NHRP                      April 1998


   One or more CIEs are specified in the NHRP Registration Request.
   Each CIE contains next hop information which a client is attempting
   to register with its servers.  Generally, all fields in CIEs enclosed
   in NHRP Registration Requests are coded as described in Section
   5.2.0.1.  However, if a station is only registering itself with the
   NHRP Registration Request then it MAY code the Cli Addr T/L, Cli
   SAddr T/L, and Cli Proto Len as zero which signifies that the client
   address information is to be taken from the source information in the
   common header (see Section 5.2.0.1).  Below, further clarification is
   given for some fields in a CIE in the context of a NHRP Registration
   Request.

     Code
       This field is set to 0x00 in NHRP Registration Requests.

     Prefix Length

       This field may be used in a NHRP Registration Request to register
       equivalence information for the Client Protocol Address specified
       in the CIE of an NHRP Registration Request In the case of NHRP
       Registration Request, the Prefix Length specifies the equivalence
       class of addresses which match the first "Prefix Length" bit
       positions of the Client Protocol Address.  If the "U" bit is set
       in the common header then this field MUST be set to 0xFF.

   The NHRP Registration Request is used to register an NHC's NHRP
   information with its NHSs.  If an NHC is configured with the protocol
   address of a serving NHS then the NHC may place the NHS's protocol
   address in the Destination Protocol Address field of the NHRP
   Registration Request common header otherwise the NHC must place its
   own protocol address in the Destination Protocol Address field.

   When an NHS receives an NHRP Registration Request which has the
   Destination Protocol Address field set to an address which belongs to
   a LIS/LAG for which the NHS is serving then if the Destination
   Protocol Address field is equal to the Source Protocol Address field
   (which would happen if the NHC put its protocol address in the
   Destination Protocol Address) or the Destination Protocol Address
   field is equal to the protocol address of the NHS then the NHS
   processes the NHRP Registration Request after doing appropriate error
   checking (including any applicable policy checking).

   When an NHS receives an NHRP Registration Request which has the
   Destination Protocol Address field set to an address which does not
   belong to a LIS/LAG for which the NHS is serving then the NHS
   forwards the packet down the routed path toward the appropriate
   LIS/LAG.




Luciani, et. al.            Standards Track                    [Page 27]

RFC 2332                       NBMA NHRP                      April 1998


   When an NHS receives an NHRP Registration Request which has the
   Destination Protocol Address field set to an address which belongs to
   a LIS/LAG for which the NHS is serving then if the Destination
   Protocol Address field does not equal the Source Protocol Address
   field and the Destination Protocol Address field does not equal the
   protocol address of the NHS then the NHS forwards the message to the
   appropriate NHS within the LIS/LAG as specified by Destination
   Protocol Address field.

   It is possible that a misconfigured station will attempt to register
   with the wrong NHS (i.e., one that cannot serve it due to policy
   constraints or routing state).  If this is the case, the NHS MUST
   reply with a NAK-ed Registration Reply of type Can't Serve This
   Address.

   If an NHS cannot serve a station due to a lack of resources, the NHS
   MUST reply with a NAK-ed Registration Reply of type Registration
   Overflow.

   In order to keep the registration entry from being discarded, the
   station MUST re-send the NHRP Registration Request packet often
   enough to refresh the registration, even in the face of occasional
   packet loss. It is recommended that the NHRP Registration Request
   packet be sent at an interval equal to one-third of the Holding Time
   specified therein.

5.2.4 NHRP Registration Reply

   The NHRP Registration Reply is sent by an NHS to a client in response
   to that client's NHRP Registration Request. If the Code field of a
   CIE in the NHRP Registration Reply has anything other than zero in it
   then the NHRP Registration Reply is a NAK otherwise the reply is an
   ACK.  The NHRP Registration Reply has a Type code of 4.

   An NHRP Registration Reply is formed from an NHRP Registration
   Request by changing the type code to 4, updating the CIE Code field,
   and filling in the appropriate extensions if they exist.  The message
   specific meanings of the fields are as follows:

   Attempts to register the information in the CIEs of an NHRP
   Registration Request may fail for various reasons.  If this is the
   case then each failed attempt to register the information in a CIE of
   an NHRP Registration Request is logged in the associated NHRP
   Registration Reply by setting the CIE Code field to the appropriate
   error code as shown below:






Luciani, et. al.            Standards Track                    [Page 28]

RFC 2332                       NBMA NHRP                      April 1998


     CIE Code

       0 - Successful Registration

         The information in the CIE was successfully registered with the
         NHS.

       4 - Administratively Prohibited

         An NHS may refuse an NHRP Registration Request attempt for
         administrative reasons (due to policy constraints or routing
         state).  If so, the NHS MUST send an NHRP Registration Reply
         which contains a NAK code of 4.

       5 - Insufficient Resources

         If an NHS cannot serve a station due to a lack of resources,
         the NHS MUST reply with a NAKed NHRP Registration Reply which
         contains a NAK code of 5.

       14 - Unique Internetworking Layer Address Already Registered
         If a client tries to register a protocol address to NBMA
         address binding with the uniqueness bit on and the protocol
         address already exists in the NHS's cache then if that cache
         entry also has the uniqueness bit on then this NAK Code is
         returned in the CIE in the NHRP Registration Reply.

   Due to the possible existence of asymmetric routing, an NHRP
   Registration Reply may not be able to merely follow the routed path
   back to the source protocol address specified in the common header of
   the NHRP Registration Reply.  As a result, there MUST exist a direct
   NBMA level connection between the NHC and its NHS on which to send
   the NHRP Registration Reply before NHRP Registration Reply may be
   returned to the NHC.  If such a connection does not exist then the
   NHS must setup such a connection to the NHC by using the source NBMA
   information supplied in the common header of the NHRP Registration
   Request.

5.2.5 NHRP Purge Request

   The NHRP Purge Request packet is sent in order to invalidate cached
   information in a station.  The NHRP Purge Request packet has a type
   code of 5.  The mandatory part of an NHRP Purge Request is coded as
   described in Section 5.2.0.1.  The message specific meanings of the
   fields are as follows:

   Flags - The flags field is coded as follows:




Luciani, et. al.            Standards Track                    [Page 29]

RFC 2332                       NBMA NHRP                      April 1998


      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |N|         unused              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     N
       When set, this bit tells the receiver of the NHRP Purge Request
       that the requester does not expect to receive an NHRP Purge
       Reply.  If an unsolicited NHRP Purge Reply is received by a
       station where that station is identified in the Source Protocol
       Address of the packet then that packet must be ignored.

   One or more CIEs are specified in the NHRP Purge Request.  Each CIE
   contains next hop information which is to be purged from an NHS/NHC
   cache.  Generally, all fields in CIEs enclosed in NHRP Purge Requests
   are coded as described in Section 5.2.0.1.  Below, further
   clarification is given for some fields in a CIE in the context of a
   NHRP Purge Request.

     Code
       This field is set to 0x00 in NHRP Purge Requests.

     Prefix Length

       In the case of NHRP Purge Requests, the Prefix Length specifies
       the equivalence class of addresses which match the first "Prefix
       Length" bit positions of the Client Protocol Address specified in
       the CIE.  All next hop information which contains a protocol
       address which matches an element of this equivalence class is to
       be purged from the receivers cache.

     The Maximum Transmission Unit and Preference fields of the CIE are
     coded as zero.  The Holding Time should be coded as zero but there
     may be some utility in supplying a "short" holding time to be
     applied to the matching next hop information before that
     information would be purged; this usage is for further study. The
     Client Protocol Address field and the Cli Proto Len field MUST be
     filled in.  The Client Protocol Address is filled in with the
     protocol address to be purged from the receiving station's cache
     while the Cli Proto Len is set the length of the purged client's
     protocol address.  All remaining fields in the CIE MAY be set to
     zero although the client NBMA information (and associated length
     fields) MAY be specified to narrow the scope of the NHRP Purge
     Request if requester desires.  However, the receiver of an NHRP
     Purge Request may choose to ignore the Client NBMA information if
     it is supplied.




Luciani, et. al.            Standards Track                    [Page 30]

RFC 2332                       NBMA NHRP                      April 1998


   An NHRP Purge Request packet is sent from an NHS to a station to
   cause it to delete previously cached information.  This is done when
   the information may be no longer valid (typically when the NHS has
   previously provided next hop information for a station that is not
   directly connected to the NBMA subnetwork, and the egress point to
   that station may have changed).

   An NHRP Purge Request packet may also be sent from an NHC to an NHS
   with which the NHC had previously registered.  This allows for an NHC
   to invalidate its registration with NHRP before it would otherwise
   expire via the holding timer. If an NHC does not have knowledge of a
   protocol address of a serving NHS then the NHC must place its own
   protocol address in the Destination Protocol Address field and
   forward the packet along the routed path.  Otherwise, the NHC must
   place the protocol address of a serving NHS in this field.

   Serving NHSs may need to send one or more new NHRP Purge Requests as
   a result of receiving a purge from one of their served NHCs since the
   NHS may have previously responded to NHRP Resolution Requests for
   that NHC's NBMA information.  These purges are "new" in that they are
   sourced by the NHS and not the NHC;  that is, for each NHC that
   previously sent a NHRP Resolution Request for the purged NHC NBMA
   information, an NHRP Purge Request is sent which contains the Source
   Protocol/NBMA Addresses of the NHS and the Destination Protocol
   Address of the NHC which previously sent an NHRP Resolution Request
   prior to the purge.

   The station sending the NHRP Purge Request MAY periodically
   retransmit the NHRP Purge Request until either NHRP Purge Request is
   acknowledged or until the holding time of the information being
   purged has expired. Retransmission strategies for NHRP Purge Requests
   are a local matter.

   When a station receives an NHRP Purge Request, it MUST discard any
   previously cached information that matches the information in the
   CIEs.

   An NHRP Purge Reply MUST be returned for the NHRP Purge Request even
   if the station does not have a matching cache entry assuming that the
   "N" bit is off in the NHRP Purge Request.

   If the station wishes to reestablish communication with the
   destination shortly after receiving an NHRP Purge Request, it should
   make an authoritative NHRP Resolution Request in order to avoid any
   stale cache entries that might be present in intermediate NHSs (See
   section 6.2.2.).  It is recommended that authoritative NHRP
   Resolution Requests be made for the duration of the holding time of
   the old information.



Luciani, et. al.            Standards Track                    [Page 31]

RFC 2332                       NBMA NHRP                      April 1998


5.2.6 NHRP Purge Reply

   The NHRP Purge Reply packet is sent in order to assure the sender of
   an NHRP Purge Request that all cached information of the specified
   type has been purged from the station sending the reply.  The NHRP
   Purge Reply has a type code of 6.

   An NHRP Purge Reply is formed from an NHRP Purge Request by merely
   changing the type code in the request to 6.  The packet is then
   returned to the requester after filling in the appropriate extensions
   if they exist.

5.2.7  NHRP Error Indication

   The NHRP Error Indication is used to convey error indications to the
   sender of an NHRP packet.  It has a type code of 7.  The Mandatory
   Part has the following format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Src Proto Len | Dst Proto Len |            unused             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Error Code          |        Error Offset           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Source NBMA Address (variable length)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source NBMA Subaddress (variable length)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Protocol Address (variable length)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Destination  Protocol Address (variable length)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Contents of NHRP Packet in error (variable length)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Src Proto Len
     This field holds the length in octets of the Source Protocol
     Address.

   Dst Proto Len
     This field holds the length in octets of the Destination Protocol
     Address.







Luciani, et. al.            Standards Track                    [Page 32]

RFC 2332                       NBMA NHRP                      April 1998


   Error Code
     An error code indicating the type of error detected, chosen from
     the following list:

       1 - Unrecognized Extension

         When the Compulsory bit of an extension in NHRP packet is set,
         the NHRP packet cannot be processed unless the extension has
         been processed.  The responder MUST return an NHRP Error
         Indication of type Unrecognized Extension if it is incapable of
         processing the extension.  However, if a transit NHS (one which
         is not going to generate a reply) detects an unrecognized
         extension, it SHALL ignore the extension.

       3 - NHRP Loop Detected

         A Loop Detected error is generated when it is determined that
         an NHRP packet is being forwarded in a loop.

       6 - Protocol Address Unreachable

         This error occurs when a packet it moving along the routed path
         and it reaches a point such that the protocol address of
         interest is not reachable.

       7 - Protocol Error

         A generic packet processing error has occurred (e.g., invalid
         version number, invalid protocol type, failed checksum, etc.)

       8 - NHRP SDU Size Exceeded

         If the SDU size of the NHRP packet exceeds the MTU size of the
         NBMA network then this error is returned.

       9 - Invalid Extension

         If an NHS finds an extension in a packet which is inappropriate
         for the packet type, an error is sent back to the sender with
         Invalid Extension as the code.

       10 - Invalid NHRP Resolution Reply Received

         If a client receives a NHRP Resolution Reply for a Next Hop
         Resolution Request which it believes it did not make then an
         error packet is sent to the station making the reply with an
         error code of Invalid Reply Received.




Luciani, et. al.            Standards Track                    [Page 33]

RFC 2332                       NBMA NHRP                      April 1998


       11 - Authentication Failure

         If a received packet fails an authentication test then this
         error is returned.

       15 - Hop Count Exceeded

         The hop count which was specified in the Fixed Header of an
         NHRP message has been exceeded.

   Error Offset
     The offset in octets into the original NHRP packet in which an
     error was detected.  This offset is calculated starting from the
     NHRP Fixed Header.

   Source NBMA Address
     The Source NBMA address field is the address of the station which
     observed the error.

   Source NBMA SubAddress
     The Source NBMA subaddress field is the address of the station
     which observed the error.  If the field's length as specified in
     ar$sstl is 0 then no storage is allocated for this address at all.

   Source Protocol Address
     This is the protocol address of the station which issued the Error
     packet.

   Destination Protocol Address
     This is the protocol address of the station which sent the packet
     which was found to be in error.

   An NHRP Error Indication packet SHALL NEVER be generated in response
   to another NHRP Error Indication packet.  When an NHRP Error
   Indication packet is generated, the offending NHRP packet SHALL be
   discarded.  In no case should more than one NHRP Error Indication
   packet be generated for a single NHRP packet.

   If an NHS sees its own Protocol and NBMA Addresses in the Source NBMA
   and Source Protocol address fields of a transiting NHRP Error
   Indication packet then the NHS will quietly drop the packet and do
   nothing (this scenario would occur when the NHRP Error Indication
   packet was itself in a loop).

   Note that no extensions may be added to an NHRP Error Indication.






Luciani, et. al.            Standards Track                    [Page 34]

RFC 2332                       NBMA NHRP                      April 1998


5.3  Extensions Part

   The Extensions Part, if present, carries one or more extensions in
   {Type, Length, Value} triplets.

   Extensions have the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |C|u|        Type               |        Length                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Value...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   C
     "Compulsory."  If clear, and the NHS does not recognize the type
     code, the extension may safely be ignored.  If set, and the NHS
     does not recognize the type code, the NHRP "request" is considered
     to be in error.  (See below for details.)

   u
     Unused and must be set to zero.

   Type
     The extension type code (see below).  The extension type is not
     qualified by the Compulsory bit, but is orthogonal to it.

   Length
     The length in octets of the value (not including the Type and
     Length fields;  a null extension will have only an extension header
     and a length of zero).

   When extensions exist, the extensions list is terminated by the Null
   TLV, having Type = 0 and Length = 0.

   Extensions may occur in any order, but any particular extension type
   may occur only once in an NHRP packet unless explicitly stated to the
   contrary in the extensions definition.  For example, the vendor-
   private extension may occur multiple times in a packet in order to
   allow for extensions which do not share the same vendor ID to be
   represented.  It is RECOMMENDED that a given vendor include no more
   than one Vendor Private Extension.

   An NHS MUST NOT change the order of extensions.  That is, the order
   of extensions placed in an NHRP packet by an NHC (or by an NHS when
   an NHS sources a packet) MUST be preserved as the packet moves
   between NHSs.  Minimal NHC implementations MUST only recognize, but



Luciani, et. al.            Standards Track                    [Page 35]

RFC 2332                       NBMA NHRP                      April 1998


   not necessarily parse, the Vendor Private extension and the End Of
   Extensions extension.  Extensions are only present in a "reply" if
   they were present in the corresponding "request" with the exception
   of Vendor Private extensions.  The previous statement is not intended
   to preclude the creation of NHS-only extensions which might be added
   to and removed from NHRP packets by the same NHS; such extensions
   MUST not be propagated to NHCs.

   The Compulsory bit provides for a means to add to the extension set.
   If the bit is set in an extension then the station responding to the
   NHRP message which contains that extension MUST be able to understand
   the extension (in this case, the station responding to the message is
   the station that would issue an NHRP reply in response to a NHRP
   request).  As a result, the responder MUST return an NHRP Error
   Indication of type Unrecognized Extension.  If the Compulsory bit is
   clear then the extension can be safely ignored; however, if an
   ignored extension is in a "request" then it MUST be returned,
   unchanged, in the corresponding "reply" packet type.

   If a transit NHS (one which is not going to generate a "reply")
   detects an unrecognized extension, it SHALL ignore the extension.  If
   the Compulsory bit is set, the transit NHS MUST NOT cache the
   information contained in the packet and MUST NOT identify itself as
   an egress router (in the Forward Record or Reverse Record
   extensions).  Effectively, this means, if a transit NHS encounters an
   extension which it cannot process and which has the Compulsory bit
   set then that NHS MUST NOT participate in any way in the protocol
   exchange other than acting as a forwarding agent.

   The NHRP extension Type space is subdivided to encourage use outside
   the IETF.

     0x0000 - 0x0FFF         Reserved for NHRP.
     0x1000 - 0x11FF         Allocated to the ATM Forum.
     0x1200 - 0x37FF         Reserved for the IETF.
     0x3800 - 0x3FFF         Experimental use.

   IANA will administer the ranges reserved for the IETF as described in
   Section 9. Values in the 'Experimental use' range have only local
   significance.

5.3.0  The End Of Extensions

    Compulsory = 1
    Type = 0
    Length = 0





Luciani, et. al.            Standards Track                    [Page 36]

RFC 2332                       NBMA NHRP                      April 1998


   When extensions exist, the extensions list is terminated by the End
   Of Extensions/Null TLV.

5.3.1  Responder Address Extension

    Compulsory = 1
    Type = 3
    Length = variable

   This extension is used to determine the address of the NHRP
   responder; i.e., the entity that generates the appropriate "reply"
   packet for a given "request" packet.  In the case of an NHRP
   Resolution Request, the station responding may be different (in the
   case of cached replies) than the system identified in the Next Hop
   field of the NHRP Resolution Reply.  Further, this extension may aid
   in detecting loops in the NHRP forwarding path.

   This extension uses a single CIE with the extension specific meanings
   of the fields set as follows:

   The Prefix Length fields MUST be set to 0 and ignored.

   CIE Code
     5 - Insufficient Resources
       If the responder to an NHRP Resolution Request is an egress point
       for the target of the address resolution request (i.e., it is one
       of the stations identified in the list of CIEs in an NHRP
       Resolution Reply) and the Responder Address extension is included
       in the NHRP Resolution Request and insufficient resources to
       setup a cut-through VC exist at the responder then the Code field
       of the Responder Address Extension is set to 5 in order to tell
       the client that a VC setup attempt would in all likelihood be
       rejected; otherwise this field MUST be coded as a zero.  NHCs MAY
       use this field to influence whether they attempt to setup a cut-
       through to the egress router.

   Maximum Transmission Unit
     This field gives the maximum transmission unit preferred by the
     responder.  If this value is 0 then either the default MTU is used
     or the MTU negotiated via signaling is used if such negotiation is
     possible for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information of the responser is considered to be valid.
     Cached information SHALL be discarded when the holding time
     expires.




Luciani, et. al.            Standards Track                    [Page 37]

RFC 2332                       NBMA NHRP                      April 1998


   "Client Address" information is actually "Responder Address"
   information for this extension.  Thus, for example, Cli Addr T/L is
   the responder NBMA address type and length field.

   If a "requester" desires this information, the "requester" SHALL
   include this extension with a value of zero.  Note that this implies
   that no storage is allocated for the Holding Time and Type/Length
   fields until the "Value" portion of the extension is filled out.

   If an NHS is generating a "reply" packet in response to a "request"
   containing this extension, the NHS SHALL include this extension,
   containing its protocol address in the "reply".  If an NHS has more
   than one protocol address, it SHALL use the same protocol address
   consistently in all of the Responder Address, Forward Transit NHS
   Record, and Reverse Transit NHS Record extensions.  The choice of
   which of several protocol address to include in this extension is a
   local matter.

   If an NHRP Resolution Reply packet being forwarded by an NHS contains
   a protocol address of that NHS in the Responder Address Extension
   then that NHS SHALL generate an NHRP Error Indication of type "NHRP
   Loop Detected" and discard the NHRP Resolution Reply.

   If an NHRP Resolution Reply packet is being returned by an
   intermediate NHS based on cached data, it SHALL place its own address
   in this extension (differentiating it from the address in the Next
   Hop field).

5.3.2  NHRP Forward Transit NHS Record Extension

    Compulsory = 1
    Type = 4
    Length = variable

   The NHRP Forward Transit NHS record contains a list of transit NHSs
   through which a "request" has traversed.  Each NHS SHALL append to
   the extension a Forward Transit NHS element (as specified below)
   containing its Protocol address.  The extension length field and the
   ar$chksum fields SHALL be adjusted appropriately.

   The responding NHS, as described in Section 5.3.1, SHALL NOT update
   this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA Address.





Luciani, et. al.            Standards Track                    [Page 38]

RFC 2332                       NBMA NHRP                      April 1998


   This extension uses a single CIE per NHS Record element with the
   extension specific meanings of the fields set as follows:

   The Prefix Length fields MUST be set to 0 and ignored.

   CIE Code
     5 - Insufficient Resources
       If an NHRP Resolution Request contains an NHRP Forward Transit
       NHS Record Extension and insufficient resources to setup a cut-
       through VC exist at the current transit NHS then the CIE Code
       field for NHRP Forward Transit NHS Record Extension is set to 5
       in order to tell the client that a VC setup attempt would in all
       likelihood be rejected; otherwise this field MUST be coded as a
       zero.  NHCs MAY use this field to influence whether they attempt
       to setup a cut-through as described in Section 2.2.  Note that
       the NHRP Reverse Transit NHS Record Extension MUST always have
       this field set to zero.

   Maximum Transmission Unit
     This field gives the maximum transmission unit preferred by the
     transit NHS.  If this value is 0 then either the default MTU is
     used or the MTU negotiated via signaling is used if such
     negotiation is possible for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information of the transit NHS is considered to be valid.
     Cached information SHALL be discarded when the holding time
     expires.

   "Client Address" information is actually "Forward Transit NHS
   Address" information for this extension.  Thus, for example, Cli Addr
   T/L is the transit NHS NBMA address type and length field.

   If a "requester" wishes to obtain this information, it SHALL include
   this extension with a length of zero.  Note that this implies that no
   storage is allocated for the Holding Time and Type/Length fields
   until the "Value" portion of the extension is filled out.

   If an NHS has more than one Protocol address, it SHALL use the same
   Protocol address consistently in all of the Responder Address,
   Forward NHS Record, and Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses to include in this extension is a
   local matter.







Luciani, et. al.            Standards Track                    [Page 39]

RFC 2332                       NBMA NHRP                      April 1998


   If a "request" that is being forwarded by an NHS contains the
   Protocol Address of that NHS in one of the Forward Transit NHS
   elements then the NHS SHALL generate an NHRP Error Indication of type
   "NHRP Loop Detected" and discard the "request".

5.3.3  NHRP Reverse Transit NHS Record Extension

    Compulsory = 1
    Type = 5
    Length = variable

   The NHRP Reverse Transit NHS record contains a list of transit NHSs
   through which a "reply" has traversed.  Each NHS SHALL append a
   Reverse Transit NHS element (as specified below) containing its
   Protocol address to this extension.  The extension length field and
   ar$chksum SHALL be adjusted appropriately.

   The responding NHS, as described in Section 5.3.1, SHALL NOT update
   this extension.

   In addition, NHSs that are willing to act as egress routers for
   packets from the source to the destination SHALL include information
   about their NBMA Address.

   This extension uses a single CIE per NHS Record element with the
   extension specific meanings of the fields set as follows:

   The CIE Code and Prefix Length fields MUST be set to 0 and ignored.

   Maximum Transmission Unit
     This field gives the maximum transmission unit preferred by the
     transit NHS.  If this value is 0 then either the default MTU is
     used or the MTU negotiated via signaling is used if such
     negotiation is possible for the given NBMA.

   Holding Time
     The Holding Time field specifies the number of seconds for which
     the NBMA information of the transit NHS is considered to be valid.
     Cached information SHALL be discarded when the holding time
     expires.

   "Client Address" information is actually "Reverse Transit NHS
   Address" information for this extension.  Thus, for example, Cli Addr
   T/L is the transit NHS NBMA address type and length field.







Luciani, et. al.            Standards Track                    [Page 40]

RFC 2332                       NBMA NHRP                      April 1998


   If a "requester" wishes to obtain this information, it SHALL include
   this extension with a length of zero.  Note that this implies that no
   storage is allocated for the Holding Time and Type/Length fields
   until the "Value" portion of the extension is filled out.

   If an NHS has more than one Protocol address, it SHALL use the same
   Protocol address consistently in all of the Responder Address,
   Forward NHS Record, and Reverse NHS Record extensions.  The choice of
   which of several Protocol addresses to include in this extension is a
   local matter.

   If a "reply" that is being forwarded by an NHS contains the Protocol
   Address of that NHS in one of the Reverse Transit NHS elements then
   the NHS SHALL generate an NHRP Error Indication of type "NHRP Loop
   Detected" and discard the "reply".

   Note that this information may be cached at intermediate NHSs;  if
   so, the cached value SHALL be used when generating a reply.

5.3.4 NHRP Authentication Extension

   Compulsory = 1 Type = 7 Length = variable

   The NHRP Authentication Extension is carried in NHRP packets to
   convey authentication information between NHRP speakers.  The
   Authentication Extension may be included in any NHRP "request" or
   "reply" only.

   The authentication is always done pairwise on an NHRP hop-by-hop
   basis;  i.e., the authentication extension is regenerated at each
   hop.  If a received packet fails the authentication test, the station
   SHALL generate an Error Indication of type "Authentication Failure"
   and discard the packet. Note that one possible authentication failure
   is the lack of an Authentication Extension; the presence or absence
   of the Authentication Extension is a local matter.

5.3.4.1 Header Format

   The authentication header has the following format:












Luciani, et. al.            Standards Track                    [Page 41]

RFC 2332                       NBMA NHRP                      April 1998


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved                    | Security Parameter Index (SPI)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Src Addr...                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+ Authentication Data... -+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Security Parameter Index (SPI) can be thought of as an index into a
   table that maintains the keys and other information such as hash
   algorithm. Src and Dst communicate either offline using manual keying
   or online using a key management protocol to populate this table. The
   sending NHRP entity always allocates the SPI and the parameters
   associated with it.

   Src Addr a variable length field is the address assigned to the
   outgoing interface. The length of the addr is obtained from the
   source protocol length field in the mandatory part of the NHRP
   header.  The tuple <spi, src addr> uniquely identifies the key and
   other parameters that are used in authentication.

   The length of the authentication data field  is dependent on the hash
   algorithm used. The data field contains the keyed hash calculated
   over the entire NHRP payload. The authentication data field is zeroed
   out before the hash is calculated.

5.3.4.2 SPI and Security Parameters Negotiation

   SPI's can be negotiated either manually or using an Internet Key
   Management protocol. Manual keying MUST be supported. The following
   parameters are associated with the tuple <SPI, src>- lifetime,
   Algorithm, Key. Lifetime indicates the duration in seconds for which
   the key is valid. In case of manual keying, this duration can be
   infinite. Also, in order to better support manual keying, there may
   be multiple tuples active at the same time (Dst being the same).

   Algorithm specifies the hash algorithm agreed upon by the two
   entities. HMAC-MD5-128 [16] is the default algorithm. Other
   algorithms MAY be supported by defining new values. IANA will assign
   the numbers to identify the algorithm being used as described in
   Section 9.

   Any Internet standard key management protocol MAY so be used to
   negotiate the SPI and parameters.



Luciani, et. al.            Standards Track                    [Page 42]

RFC 2332                       NBMA NHRP                      April 1998


5.3.4.3 Message Processing

   At the time of adding the authentication extension header, src looks
   up in a table to fetch the SPI and the security parameters based on
   the outgoing interface address. If there are no entries in the table
   and if there is support for key management, the src initiates the key
   management protocol to fetch the necessary parameters. The src
   constructs the Authentication Extension payload and calculates the
   hash by zeroing authentication data field. The result replaces in the
   zeroed authentication data field. The src address field in the
   payload is the IP address assigned to the outgoing interface.

   If key management is not supported and authentication is mandatory,
   the packet is dropped and this information is logged.

   On the receiving end, dst fetches the parameters based on the SPI and
   the ip address in the authentication extension payload. The
   authentication data field is extracted before zeroing out to
   calculate the hash. It computes the hash on the entire payload and if
   the hash does not match, then an "abnormal event" has occurred.

5.3.4.4 Security Considerations

   It is important that the keys chosen are strong as the security of
   the entire system depends on the keys being chosen properly and the
   correct implementation of the algorithms.

   The security is performed on a hop by hop basis. The data received
   can be trusted only so much as one trusts all the entities in the
   path traversed. A chain of trust is established amongst NHRP entities
   in the path of the NHRP Message . If the security in an NHRP entity
   is compromised, then security in the entire NHRP domain is
   compromised.

   Data integrity covers the entire NHRP payload. This guarantees that
   the message was not modified and the source is authenticated as well.
   If authentication extension is not used or if the security is
   compromised, then NHRP entities are liable to both spoofing attacks,
   active attacks and passive attacks.

   There is no mechanism to encrypt the messages. It is assumed that a
   standard layer 3 confidentiality mechanism will be used to encrypt
   and decrypt messages.  It is recommended to use an Internet standard
   key management protocol to negotiate the keys between the neighbors.
   Transmitting the keys in clear text, if other methods of negotiation
   is used, compromises the security completely.





Luciani, et. al.            Standards Track                    [Page 43]

RFC 2332                       NBMA NHRP                      April 1998


   Any NHS is susceptible to Denial of Service (DOS) attacks that cause
   it to become overloaded, preventing legitimate packets from being
   acted upon properly. A rogue host can send request and registration
   packets to the first hop NHS. If the authentication option is not
   used, the registration packet is forwarded along the routed path
   requiring processing along each NHS. If the authentication option is
   used, then only the first hop NHS is susceptible to DOS attacks
   (i.e., unauthenticated packets will be dropped rather than forwarded
   on). If security of any host is compromised (i.e., the keys it is
   using to communicate with an NHS become known), then a rogue host can
   send NHRP packets to the first hop NHS of the host whose keys were
   compromised, which will then forward them along the routed path as in
   the case of unauthenticated packets.  However, this attack requires
   that the rogue host to have the same first hop NHS as that of the
   compromised host. Finally, it should be noted that denial of service
   attacks that cause routers on the routed path to expend resources
   processing NHRP packets are also susceptable to attacks that flood
   packets at the same destination as contained in an NHRP packet's
   Destination Protocol Address field.

5.3.5  NHRP Vendor-Private Extension

    Compulsory = 0
    Type = 8
    Length = variable

   The NHRP Vendor-Private Extension is carried in NHRP packets to
   convey vendor-private information or NHRP extensions between NHRP
   speakers.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Vendor ID                    |  Data....     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Vendor ID
     802 Vendor ID as assigned by the IEEE [6]

   Data
     The remaining octets after the Vendor ID in the payload are
     vendor-dependent data.

   This extension may be added to any "request" or "reply" packet and it
   is the only extension that may be included multiple times.  If the
   receiver does not handle this extension, or does not match the Vendor





Luciani, et. al.            Standards Track                    [Page 44]

RFC 2332                       NBMA NHRP                      April 1998


   ID in the extension then the extension may be completely ignored by
   the receiver.  If a Vendor Private Extension is included in a
   "request" then it must be copied to the corresponding "reply".

6. Protocol Operation

   In this section, we discuss certain operational considerations of
   NHRP.

6.1 Router-to-Router Operation

   In practice, the initiating and responding stations may be either
   hosts or routers.  However, there is a possibility under certain
   conditions that a stable routing loop may occur if NHRP is used
   between two routers.  In particular, attempting to establish an NHRP
   path across a boundary where information used in route selection is
   lost may result in a routing loop.  Such situations include the loss
   of BGP path vector information, the interworking of multiple routing
   protocols with dissimilar metrics (e.g, RIP and OSPF), etc.  In such
   circumstances, NHRP should not be used.  This situation can be
   avoided if there are no "back door" paths between the entry and
   egress router outside of the NBMA subnetwork.  Protocol mechanisms to
   relax these restrictions are under investigation.

   In general it is preferable to use mechanisms, if they exist, in
   routing protocols to resolve the egress point when the destination
   lies outside of the NBMA subnetwork, since such mechanisms will be
   more tightly coupled to the state of the routing system and will
   probably be less likely to create loops.

6.2 Cache Management Issues

   The management of NHRP caches in the source station, the NHS serving
   the destination, and any intermediate NHSs is dependent on a number
   of factors.

6.2.1 Caching Requirements

   Source Stations

     Source stations MUST cache all received NHRP Resolution Replies
     that they are actively using.  They also must cache "incomplete"
     entries, i.e., those for which a NHRP Resolution Request has been
     sent but those for which an NHRP Resolution Reply has not been
     received.  This is necessary in order to preserve the Request ID






Luciani, et. al.            Standards Track                    [Page 45]

RFC 2332                       NBMA NHRP                      April 1998


     for retries, and provides the state necessary to avoid triggering
     NHRP Resolution Requests for every data packet sent to the
     destination.

     Source stations MUST purge expired information from their caches.
     Source stations MUST purge the appropriate cached information upon
     receipt of an NHRP Purge Request packet.

     When a station has a co-resident NHC and NHS, the co-resident NHS
     may reply to NHRP Resolution Requests from the co-resident NHC with
     information which the station cached as a result of the co-resident
     NHC making its own NHRP Resolution Requests as long as the co-
     resident NHS follows the rules for Transit NHSs as seen below.

   Serving NHSs

     The NHS serving the destination (the one which responds
     authoritatively to NHRP Resolution Requests) SHOULD cache protocol
     address information from all NHRP Resolution Requests to which it
     has responded if the information in the NHRP Resolution Reply has
     the possibility of changing during its lifetime (so that an NHRP
     Purge Request packet can be issued). The internetworking to NBMA
     binding information provided by the source station in the NHRP
     Resolution Request may also be cached if and only if the "S" bit is
     set, the NHRP Resolution Request has included a CIE with the
     Holding Time field set greater than zero (this is the valid Holding
     Time for the source binding), and only for non-authoritative use
     for a period not to exceed the Holding Time.

   Transit NHSs

     A Transit NHS (lying along the NHRP path between the source station
     and the responding NHS) may cache source binding information
     contained in NHRP Resolution Request packets that it forwards if
     and only if the "S" bit is set, the NHRP Resolution Request has
     included a CIE with the Holding Time field set greater than zero
     (this is the valid Holding Time for the source binding), and only
     for non-authoritative use for a period not to exceed the Holding
     Time.

     A Transit NHS may cache destination information contained in NHRP
     Resolution Reply CIE if only if the D bit is set and then only for
     non-authoritative use for a period not to exceed the Holding Time
     value contained in the CIE.  A Transit NHS MUST NOT cache source
     binding information contained in an NHRP Resolution Reply.






Luciani, et. al.            Standards Track                    [Page 46]

RFC 2332                       NBMA NHRP                      April 1998


     Further, a transit NHS MUST discard any cached information when the
     prescribed time has expired.  It may return cached information in
     response to non-authoritative NHRP Resolution Requests only.

6.2.2 Dynamics of Cached Information

   NBMA-Connected Destinations

     NHRP's most basic function is that of simple NBMA address
     resolution of stations directly attached to the NBMA subnetwork.
     These mappings are typically very static, and appropriately chosen
     holding times will minimize problems in the event that the NBMA
     address of a station must be changed. Stale information will cause
     a loss of connectivity, which may be used to trigger an
     authoritative NHRP Resolution Request and bypass the old data.  In
     the worst case, connectivity will fail until the cache entry times
     out.

     This applies equally to information marked in NHRP Resolution
     Replies as being "stable" (via the "D" bit).

   Destinations Off of the NBMA Subnetwork

     If the source of an NHRP Resolution Request is a host and the
     destination is not directly attached to the NBMA subnetwork, and
     the route to that destination is not considered to be "stable," the
     destination mapping may be very dynamic (except in the case of a
     subnetwork where each destination is only singly homed to the NBMA
     subnetwork).  As such the cached information may very likely become
     stale.  The consequence of stale information in this case will be a
     suboptimal path (unless the internetwork has partitioned or some
     other routing failure has occurred).

6.3 Use of the Prefix Length field of a CIE

   A certain amount of care needs to be taken when using the Prefix
   Length field of a CIE, in particular with regard to the prefix length
   advertised (and thus the size of the equivalence class specified by
   it).  Assuming that the routers on the NBMA subnetwork are exchanging
   routing information, it should not be possible for an NHS to create a
   black hole by advertising too large of a set of destinations, but
   suboptimal routing (e.g., extra internetwork layer hops through the
   NBMA) can result.  To avoid this situation an NHS that wants to send
   the Prefix Length MUST obey the following rule:

     The NHS examines the Network Layer Reachability Information (NLRI)
     associated with the route that the NHS would use to forward towards
     the destination (as specified by the Destination internetwork layer



Luciani, et. al.            Standards Track                    [Page 47]

RFC 2332                       NBMA NHRP                      April 1998


     address in the NHRP Resolution Request), and extracts from this
     NLRI the shortest address prefix such that: (a) the Destination
     internetwork layer address (from the NHRP Resolution Request) is
     covered by the prefix, (b) the NHS does not have any routes with
     NLRI which form a subset of what is covered by the prefix. The
     prefix may then be used in the CIE.

   The Prefix Length field of the CIE should be used with restraint, in
   order to avoid NHRP stations choosing suboptimal transit paths when
   overlapping prefixes are available.  This document specifies the use
   of the prefix length only when all the destinations covered by the
   prefix are "stable". That is, either:

     (a) All destinations covered by the prefix are on the NBMA network,
         or
     (b) All destinations covered by the prefix are directly attached to
         the NHRP responding station.

   Use of the Prefix Length field of the CIE in other circumstances is
   outside the scope of this document.

6.4 Domino Effect

   One could easily imagine a situation where a router, acting as an
   ingress station to the NBMA subnetwork, receives a data packet, such
   that this packet triggers an NHRP Resolution Request.  If the router
   forwards this data packet without waiting for an NHRP transit path to
   be established, then when the next router along the path receives the
   packet, the next router may do exactly the same - originate its own
   NHRP Resolution Request (as well as forward the packet).  In fact
   such a data packet may trigger NHRP Resolution Request generation at
   every router along the path through an NBMA subnetwork.  We refer to
   this phenomena as the NHRP "domino" effect.

   The NHRP domino effect is clearly undesirable.  At best it may result
   in excessive NHRP traffic.  At worst it may result in an excessive
   number of virtual circuits being established unnecessarily.
   Therefore, it is important to take certain measures to avoid or
   suppress this behavior.  NHRP implementations for NHSs MUST provide a
   mechanism to address this problem. One possible strategy to address
   this problem would be to configure a router in such a way that NHRP
   Resolution Request generation by the router would be driven only by
   the traffic the router receives over its non-NBMA interfaces
   (interfaces that are not attached to an NBMA subnetwork).  Traffic
   received by the router over its NBMA-attached interfaces would not
   trigger NHRP Resolution Requests.  Such a router avoids the NHRP
   domino effect through administrative means.




Luciani, et. al.            Standards Track                    [Page 48]

RFC 2332                       NBMA NHRP                      April 1998


7. NHRP over Legacy BMA Networks

   There would appear to be no significant impediment to running NHRP
   over legacy broadcast subnetworks.  There may be issues around
   running NHRP across multiple subnetworks. Running NHRP on broadcast
   media has some interesting possibilities; especially when setting up
   a cut-through for inter-ELAN inter-LIS/LAG traffic when one or both
   end stations are legacy attached.  This use for NHRP requires further
   research.

8. Discussion

   The result of an NHRP Resolution Request depends on how routing is
   configured among the NHSs of an NBMA subnetwork.  If the destination
   station is directly connected to the NBMA subnetwork and the routed
   path to it lies entirely within the NBMA subnetwork, the NHRP
   Resolution Replies always return the NBMA address of the destination
   station itself rather than the NBMA address of some egress router.
   On the other hand, if the routed path exits the NBMA subnetwork, NHRP
   will be unable to resolve the NBMA address of the destination, but
   rather will return the address of the egress router.  For
   destinations outside the NBMA subnetwork, egress routers and routers
   in the other subnetworks should exchange routing information so that
   the optimal egress router may be found.

   In addition to NHSs, an NBMA station could also be associated with
   one or more regular routers that could act as "connectionless
   servers" for the station.  The station could then choose to resolve
   the NBMA next hop or just send the packets to one of its
   connectionless servers.  The latter option may be desirable if
   communication with the destination is short-lived and/or doesn't
   require much network resources.  The connectionless servers could, of
   course, be physically integrated in the NHSs by augmenting them with
   internetwork layer switching functionality.

9. IANA Considerations

   IANA will take advice from the Area Director appointed designated
   subject matter expert, in order to assign numbers from the various
   number spaces described herein.  In the event that the Area Director
   appointed designated subject matter expert is unavailable, the
   relevant IESG Area Director will appoint another expert.  Any and all
   requests for value assignment within a given number space will be
   accepted when the usage of the value assignment documented.  Possible
   forms of documentantion include, but is not limited to, RFCs or the
   product of another cooperative standards body (e.g., the MPOA and
   LANE subworking group of the ATM Forum).




Luciani, et. al.            Standards Track                    [Page 49]

RFC 2332                       NBMA NHRP                      April 1998


References

   [1] Heinanen, J., and R. Govindan, "NBMA Address Resolution Protocol
   (NARP)", RFC 1735, December 1994.

   [2] Plummer, D., "Address Resolution Protocol", STD 37, RFC 826,
   November 1982.

   [3] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC
   2225, April 1998.

   [4] Piscitello,, D., and J. Lawrence, "Transmission of IP datagrams
   over the SMDS service", RFC 1209, March 1991.

   [5] Protocol Identification in the Network Layer, ISO/IEC TR
   9577:1990.

   [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
   October 1994.

   [7] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
   Layer 5", RFC 1483, July 1993.

   [8] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
   Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August
   1992.

   [9] Bradley, T., Brown, C., and A. Malis, "Multiprotocol Interconnect
   over Frame Relay", RFC 1490, July 1993.

   [10] Rekhter, Y., and D. Kandlur, ""Local/Remote" Forwarding Decision
   in Switched Data Link Subnetworks", RFC 1937, May 1996.

   [11] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
   Networks", RFC 2022, November 1996.

   [12] Luciani, J., Armitage, G., and J. Halpern, "Server Cache
   Synchronization Protocol (SCSP) - NBMA", RFC 2334, April 1998.

   [13] Rekhter, Y., "NHRP for Destinations off the NBMA Subnetwork",
   Work In Progress.

   [14] Luciani, J., et. al., "Classical IP and ARP over ATM to NHRP
   Transition", Work In Progress.

   [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.




Luciani, et. al.            Standards Track                    [Page 50]

RFC 2332                       NBMA NHRP                      April 1998


   [16] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing
   for Message Authentication", RFC 2104, February 1997.

Acknowledgments

   We would like to thank (in no particular order) Thomas Narten of IBM
   for his comments in the role of Internet AD, Juha Heinenan of Telecom
   Finland and Ramesh Govidan of ISI for their work on NBMA ARP and the
   original NHRP draft, which served as the basis for this work.
   Russell Gardo of IBM, John Burnett of Adaptive, Dennis Ferguson of
   ANS, Andre Fredette of Bay Networks, Joel Halpern of Newbridge, Paul
   Francis of NTT, Tony Li, Bryan Gleeson, and Yakov Rekhter of cisco,
   and Grenville Armitage of Bellcore should also be acknowledged for
   comments and suggestions that improved this work substantially.  We
   would also like to thank the members of the ION working group of the
   IETF, whose review and discussion of this document have been
   invaluable.

Authors' Addresses

   James V. Luciani                    Dave Katz
   Bay Networks                        cisco Systems
   3 Federal Street                    170 W. Tasman Dr.
   Mail Stop: BL3-03                   San Jose, CA 95134 USA
   Billerica, MA 01821                 Phone:  +1 408 526 8284
   Phone:  +1 978 916 4734             EMail:  dkatz@cisco.com
   EMail:  luciani@baynetworks.com

   David Piscitello                    Bruce Cole
   Core Competence                     Juniper Networks
   1620 Tuckerstown Road               3260 Jay St.
   Dresher, PA 19025 USA               Santa Clara, CA 95054
   Phone:  +1 215 830 0692             Phone:  +1 408 327 1900
   EMail: dave@corecom.com             EMail:  bcole@jnx.com

   Naganand Doraswamy
   Bay Networks, Inc.
   3 Federal Street
   Mail Stop: Bl3-03
   Billerica, MA 01801
   Phone:  +1 978 916 1323
   EMail: naganand@baynetworks.com









Luciani, et. al.            Standards Track                    [Page 51]

RFC 2332                       NBMA NHRP                      April 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Luciani, et. al.            Standards Track                    [Page 52]