File: rfc1256.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 (1067 lines) | stat: -rw-r--r-- 43,562 bytes parent folder | download | duplicates (8)
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






Network Working Group                                 S. Deering, Editor
Request for Comments: 1256                                    Xerox PARC
                                                          September 1991


                     ICMP Router Discovery Messages

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   This document is a product of the IETF Router Discovery Working
   Group.  Distribution of this memo is unlimited.

Abstract

   This document specifies an extension of the Internet Control Message
   Protocol (ICMP) to enable hosts attached to multicast or broadcast
   networks to discover the IP addresses of their neighboring routers.

Table of Contents

   1. Terminology                                                      1
   2. Protocol Overview                                                3
   3. Message Formats                                                  5
   4. Router Specification                                             7
        4.1. Router Configuration Variables                            7
        4.2. Message Validation by Routers                             9
        4.3. Router Behavior                                           9
   5. Host Specification                                              12
        5.1. Host Configuration Variables                             12
        5.2. Message Validation by Hosts                              13
        5.3. Host Behavior                                            14
   6. Protocol Constants                                              17
   7. Security Considerations                                         17
   References                                                         18
   Author's Address                                                   19

1. Terminology

   The following terms have a precise meaning when used in this
   document:

   system        a device that implements the Internet Protocol, IP [9].

   router        a system that forwards IP datagrams, as specified



Router Discovery Working Group                                  [Page 1]

RFC 1256             ICMP Router Discovery Messages       September 1991


                 in [2].  This does not include systems that, though
                 capable of IP forwarding, have that capability turned
                 off.  Nor does it include systems that do IP forwarding
                 only insofar as required to obey IP Source Route
                 options.

   host          any system that is not a router.

   multicast     unless otherwise qualified, means the use of either IP
                 multicast [4] or IP broadcast [6] service.

   link          a communication facility or medium over which systems
                 can communicate at the link layer, i.e., the protocol
                 layer immediately below IP.  The term "physical
                 network" has sometimes been used (imprecisely) for
                 this. Examples of links are LANs (possibly bridged to
                 other LANs), wide-area store-and-forward networks,
                 satellite channels, and point-to-point links.

   multicast link
                 a link over which IP multicast or IP broadcast service
                 is supported.  This includes broadcast media such as
                 LANs and satellite channels, single point-to-point
                 links, and some store-and-forward networks such as SMDS
                 networks [8].

   interface     a system's attachment point to a link.  It is possible
                 (though unusual) for a system to have more than one
                 interface to the same link.  Interfaces are uniquely
                 identified by IP unicast addresses; a single interface
                 may have more than one such address.

   multicast interface
                 an interface to a multicast link, that is, an interface
                 to a link over which IP multicast or IP broadcast
                 service is supported.

   subnet        either a single subnet of a subnetted IP network [7] or
                 a single non-subnetted IP network, i.e., the entity
                 identified by an IP address logically ANDed with its
                 assigned subnet mask.  More than one subnet may exist
                 on the same link.

   neighboring   having an IP address belonging to the same subnet.







Router Discovery Working Group                                  [Page 2]

RFC 1256             ICMP Router Discovery Messages       September 1991


2. Protocol Overview

   Before a host can send IP datagrams beyond its directly-attached
   subnet, it must discover the address of at least one operational
   router on that subnet. Typically, this is accomplished by reading a
   list of one or more router addresses from a (possibly remote)
   configuration file at startup time.  On multicast links, some hosts
   also discover router addresses by listening to routing protocol
   traffic.  Both of these methods have serious drawbacks: configuration
   files must be maintained manually -- a significant administrative
   burden -- and are unable to track dynamic changes in router
   availability; eavesdropping on routing traffic requires that hosts
   recognize the particular routing protocols in use, which vary from
   subnet to subnet and which are subject to change at any time.  This
   document specifies an alternative router discovery method using a
   pair of ICMP [10] messages, for use on multicast links.  It
   eliminates the need for manual configuration of router addresses and
   is independent of any specific routing protocol.

   The ICMP router discovery messages are called "Router Advertisements"
   and "Router Solicitations".  Each router periodically multicasts a
   Router Advertisement from each of its multicast interfaces,
   announcing the IP address(es) of that interface.  Hosts discover the
   addresses of their neighboring routers simply by listening for
   advertisements.  When a host attached to a multicast link starts up,
   it may multicast a Router Solicitation to ask for immediate
   advertisements, rather than waiting for the next periodic ones to
   arrive; if (and only if) no advertisements are forthcoming, the host
   may retransmit the solicitation a small number of times, but then
   must desist from sending any more solicitations.  Any routers that
   subsequently start up, or that were not discovered because of packet
   loss or temporary link partitioning, are eventually discovered by
   reception of their periodic (unsolicited) advertisements.  (Links
   that suffer high packet loss rates or frequent partitioning are
   accommodated by increasing the rate of advertisements, rather than
   increasing the number of solicitations that hosts are permitted to
   send.)

   The router discovery messages do not constitute a routing protocol:
   they enable hosts to discover the existence of neighboring routers,
   but not which router is best to reach a particular destination.  If a
   host chooses a poor first-hop router for a particular destination, it
   should receive an ICMP Redirect from that router, identifying a
   better one.

   A Router Advertisement includes a "preference level" for each
   advertised router address.  When a host must choose a default router
   address (i.e., when, for a particular destination, the host has not



Router Discovery Working Group                                  [Page 3]

RFC 1256             ICMP Router Discovery Messages       September 1991


   been redirected or configured to use a specific router address), it
   is expected to choose from those router addresses that have the
   highest preference level (see Section 3.3.1 in the Host Requirements
   -- Communication Layers RFC [1]).  A network administrator can
   configure router address preference levels to encourage or discourage
   the use of particular routers as default routers.

   A Router Advertisement also includes a "lifetime" field, specifying
   the maximum length of time that the advertised addresses are to be
   considered as valid router addresses by hosts, in the absence of
   further advertisements.  This is used to ensure that hosts eventually
   forget about routers that fail, become unreachable, or stop acting as
   routers.

   The default advertising rate is once every 7 to 10 minutes, and the
   default lifetime is 30 minutes.  This means that, using the default
   values, the advertisements are not sufficient as a mechanism for
   "black hole" detection, i.e., detection of failure of the first hop
   of an active path -- ideally, black holes should be detected quickly
   enough to switch to another router before any transport connections
   or higher-layer sessions time out.  It is assumed that hosts already
   have mechanisms for black hole detection, as required by [1].  Hosts
   cannot depend on Router Advertisements for this purpose, since they
   may be unavailable or administratively disabled on any particular
   link or from any particular router.  Therefore, the default
   advertising rate and lifetime values were chosen simply to make the
   load imposed on links and hosts by the periodic multicast
   advertisements negligible, even when there are many routers present.
   However, a network administrator who wishes to employ advertisements
   as a supplemental black hole detection mechanism is free to configure
   smaller values.




















Router Discovery Working Group                                  [Page 4]

RFC 1256             ICMP Router Discovery Messages       September 1991


3. Message Formats


   ICMP Router Advertisement Message

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Num Addrs   |Addr Entry Size|           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Router Address[1]                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Preference Level[1]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Router Address[2]                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Preference Level[2]                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               .                               |
      |                               .                               |
      |                               .                               |


   IP Fields:

      Source Address        An IP address belonging to the interface
                            from which this message is sent.

      Destination Address   The configured AdvertisementAddress or the
                            IP address of a neighboring host.

      Time-to-Live          1 if the Destination Address is an IP
                            multicast address; at least 1 otherwise.


   ICMP Fields:

      Type                  9

      Code                  0

      Checksum              The  16-bit one's complement of the one's
                            complement sum of the ICMP message, start-
                            ing with the ICMP Type.  For computing the
                            checksum, the Checksum field is set to 0.




Router Discovery Working Group                                  [Page 5]

RFC 1256             ICMP Router Discovery Messages       September 1991


      Num Addrs             The number of router addresses advertised
                            in this message.

      Addr Entry Size       The number of 32-bit words of information
                            per each router address (2, in the version
                            of the protocol described here).

      Lifetime              The maximum number of seconds that the
                            router addresses may be considered valid.

      Router Address[i],    The sending router's IP address(es) on the
       i = 1..Num Addrs     interface from which this message is sent.

      Preference Level[i],  The preferability of each Router Address[i]
       i = 1..Num Addrs     as a default router address, relative to
                            other router addresses on the same subnet.
                            A signed, twos-complement value; higher
                            values mean more preferable.


   ICMP Router Solicitation Message

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |           Checksum            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   IP Fields:

      Source Address        An IP address belonging to the interface
                            from which this message is sent, or 0.

      Destination Address   The configured SolicitationAddress.

      Time-to-Live          1 if the Destination Address is an IP
                            multicast address; at least 1 otherwise.


   ICMP Fields:

      Type                  10

      Code                  0




Router Discovery Working Group                                  [Page 6]

RFC 1256             ICMP Router Discovery Messages       September 1991


      Checksum              The  16-bit one's complement of the one's
                            complement sum of the ICMP message, start-
                            ing with the ICMP Type.  For computing the
                            checksum, the Checksum field is set to 0.

      Reserved              Sent as 0; ignored on reception.


4. Router Specification

4.1. Router Configuration Variables

   A router that implements the ICMP router discovery messages must
   allow for the following variables to be configured by system
   management; default values are specified so as to make it unnecessary
   to configure any of these variables in many cases.

   For each multicast interface:

   AdvertisementAddress
                 The IP destination address to be used for multicast
                 Router Advertisements sent from the interface.  The
                 only permissible values are the all-systems multicast
                 address, 224.0.0.1, or the limited-broadcast address,
                 255.255.255.255.  (The all-systems address is preferred
                 wherever possible, i.e., on any link where all
                 listening hosts support IP multicast.)

                 Default: 224.0.0.1 if the router supports IP multicast
                 on the interface, else 255.255.255.255

   MaxAdvertisementInterval
                 The maximum time allowed between sending multicast
                 Router Advertisements from the interface, in seconds.
                 Must be no less than 4 seconds and no greater than 1800
                 seconds.

                 Default: 600 seconds

   MinAdvertisementInterval
                 The minimum time allowed between sending unsolicited
                 multicast Router Advertisements from the interface, in
                 seconds.  Must be no less than 3 seconds and no greater
                 than MaxAdvertisementInterval.

                 Default: 0.75 * MaxAdvertisementInterval





Router Discovery Working Group                                  [Page 7]

RFC 1256             ICMP Router Discovery Messages       September 1991


   AdvertisementLifetime
                 The value to be placed in the Lifetime field of Router
                 Advertisements sent from the interface, in seconds.
                 Must be no less than MaxAdvertisementInterval and no
                 greater than 9000 seconds.

                 Default: 3 * MaxAdvertisementInterval


   For each of the router's IP addresses on its multicast interfaces:

   Advertise
                 A flag indicating whether or not the address is to be
                 advertised.

                 Default: TRUE

   PreferenceLevel
                 The preferability of the address as a default router
                 address, relative to other router addresses on the same
                 subnet.  A 32-bit, signed, twos-complement integer,
                 with higher values meaning more preferable.  The
                 minimum value (hex 80000000) is used to indicate that
                 the address, even though it may be advertised, is not
                 to be used by neighboring hosts as a default router
                 address.

                 Default: 0

   The case in which it is useful to configure an address with a
   preference level of hex 80000000 (rather than simply setting its
   Advertise flag to FALSE) is when advertisements are being used for
   "black hole" detection, as mentioned in Section 2.  In particular, a
   router that is to be used to reach only specific IP destinations
   could advertise its address with a preference level of hex 80000000
   (so that neighboring hosts will not use it as a default router for
   reaching arbitrary IP destinations) and a non-zero lifetime (so that
   neighboring hosts that have been redirected or configured to use it
   can detect its failure by timing out the reception of its
   advertisements).

   It has been suggested that, when the preference level of an address
   has not been explicitly configured, a router could set it according
   to the metric of the router's "default route" (if it has one), rather
   than defaulting it to zero as suggested above.  Thus, a router with a
   better metric for its default route would advertise a higher
   preference level for its address.  (Note that routing metrics that
   are encoded such that "lower is better" would have to be inverted



Router Discovery Working Group                                  [Page 8]

RFC 1256             ICMP Router Discovery Messages       September 1991


   before being used as preference levels in Router Advertisement
   messages.)  Such a strategy might reduce the amount of ICMP Redirect
   traffic on some links by making it more likely that a host's first
   choice router for reaching an arbitrary destination is also the best
   choice.  On the other hand, Redirect traffic is rarely a significant
   load on a link, and there are some cases where such a strategy would
   result in more Redirect traffic, not less (for example, on links from
   which the most frequently chosen destinations are best reached via
   routers other than the one with the best default route).  This
   document makes no recommendation concerning this issue, and
   implementors are free to try such a strategy, as long as they also
   support static configuration of preference levels as specified above.

4.2. Message Validation by Routers

   A router must silently discard any received Router Solicitation
   messages that do not satisfy the following validity checks:

      - IP Source Address is either 0 or the address of a neighbor
        (i.e., an address that matches one of the router's own
        addresses on the arrival interface, under the subnet mask
        associated with that address.)

      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP length (derived from the IP length) is 8 or more
        octets.

   The contents of the ICMP Reserved field, and of any octets beyond the
   first 8, are ignored.  Future, backward-compatible changes to the
   protocol may specify the contents of the Reserved field or of
   additional octets at the end of the message; backward-incompatible
   changes may use different Code values.

   A solicitation that passes the validity checks is called a "valid
   solicitation".

   A router may silently discard any received Router Advertisement
   messages.  Any other action on reception of such messages by a router
   (for example, as part of a "peer discovery" process) is beyond the
   scope of this document.

4.3. Router Behavior

   The router joins the all-routers IP multicast group (224.0.0.2) on
   all interfaces on which the router supports IP multicast.



Router Discovery Working Group                                  [Page 9]

RFC 1256             ICMP Router Discovery Messages       September 1991


   The term "advertising interface" refers to any functioning and
   enabled multicast interface that has at least one IP address whose
   configured Advertise flag is TRUE.  From each advertising interface,
   the router transmits periodic, multicast Router Advertisements,
   containing the following values:

      - In the destination address field of the IP header: the
        interface's configured AdvertisementAddress.

      - In the Lifetime field: the interface's configured
        AdvertisementLifetime.

      - In the Router Address[i] and Preference Level[i] fields:
        all of the interface's addresses whose Advertise flags are
        TRUE, along with their corresponding PreferenceLevel
        values.  (In the unlikely event that not all addresses fit
        in a single advertisement, as constrained by the MTU of the
        link, multiple advertisements are sent, with each except
        the last containing as many addresses as can fit.)

   The advertisements are not strictly periodic: the interval between
   subsequent transmissions is randomized to reduce the probability of
   synchronization with the advertisements from other routers on the
   same link. This is done by maintaining a separate transmission
   interval timer for each advertising interface.  Each time a multicast
   advertisement is sent from an interface, that interface's timer is
   reset to a uniformly-distributed random value between the interface's
   configured MinAdvertisementInterval and MaxAdvertisementInterval;
   expiration of the timer causes the next advertisement to be sent from
   the interface, and a new random value to be chosen.  (It is
   recommended that routers include some unique value, such as one of
   their IP or link-layer addresses, in the seed used to initialize
   their pseudo-random number generators.  Although the randomization
   range is configured in units of seconds, the actual randomly-chosen
   values should not be in units of whole seconds, but rather in units
   of the highest available timer resolution.)

   For the first few advertisements sent from an interface (up to
   MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is
   greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to
   MAX_INITIAL_ADVERT_INTERVAL instead.  Using this smaller interval for
   the initial advertisements increases the likelihood of a router being
   discovered quickly when it first becomes available, in the presence
   of possible packet loss.

   In addition to the periodic, unsolicited advertisements, a router
   sends advertisements in response to valid solicitations received on
   any of its advertising interfaces.  A router may choose to unicast



Router Discovery Working Group                                 [Page 10]

RFC 1256             ICMP Router Discovery Messages       September 1991


   the response directly to the soliciting host's address (if it is not
   zero), or multicast it to the interface's configured
   AdvertisementAddress; in the latter case, the interface's interval
   timer is reset to a new random value, as with unsolicited
   advertisements.  A unicast response may be delayed, and a multicast
   response must be delayed, for a small random interval not greater
   than MAX_RESPONSE_DELAY, in order to prevent synchronization with
   other responding routers, and to allow multiple, closely-spaced
   solicitations to be answered with a single multicast advertisement.

   If a router receives a solicitation sent to an IP broadcast address,
   on an interface whose configured AdvertisementAddress is an IP
   multicast address, the router may send its response to the IP
   broadcast address instead of the configured IP multicast address.
   Such an event indicates a configuration inconsistency, and should be
   logged for possible corrective action by the network administrator.

   It should be noted that an interface may become an advertising
   interface at times other than system startup, as a result of recovery
   from an interface failure or through actions of system management
   such as:

      - enabling the interface, if it had been administratively
        disabled and it has one or more addresses whose Advertise
        flag is TRUE, or

      - enabling IP forwarding capability (i.e., changing the
        system from being a host to being a router), when the
        interface has one or more addresses whose Advertise flag is
        TRUE, or

      - setting the Advertise flag of one or more of the
        interface's addresses to TRUE (or adding a new address with
        a TRUE Advertise flag), when previously the interface had
        no address whose Advertise flag was TRUE.

In such cases, the router must commence transmission of periodic
advertisements on the new advertising interface, limiting the first few
advertisements to intervals no greater than MAX_INITIAL_ADVERT_INTERVAL.
In the case of a host becoming a router, the system must also join the
all-routers IP multicast group on all interfaces on which the router
supports IP multicast (whether or not they are advertising interfaces).

An interface may also cease to be an advertising interface, through
actions of system management such as:

      - administratively disabling the interface,




Router Discovery Working Group                                 [Page 11]

RFC 1256             ICMP Router Discovery Messages       September 1991


      - shutting down the system, or disabling the IP forwarding
        capability (i.e., changing the system from being a router
        to being a host), or

      - setting the Advertise flags of all of the interface's
        addresses to FALSE.

   In such cases, it is recommended (but not required) that the router
   transmit a final multicast advertisement on the interface, identical
   to its previous transmission but with a Lifetime field of zero.  In
   the case of a router becoming a host, the system must also depart
   from the all-routers IP multicast group on all interfaces on which
   the router supports IP multicast (whether or not they had been
   advertising interfaces).

   When the Advertise flag of one or more of an interface's addresses
   are set to FALSE by system management, but there remain other
   addresses on that interface whose Advertise flags are TRUE, it is
   recommended that the router send a single multicast advertisement
   containing only those address whose Advertise flags were set to
   FALSE, with a Lifetime field of zero.

5. Host Specification

5.1. Host Configuration Variables

   A host that implements the ICMP router discovery messages must allow
   for the following variables to be configured by system management;
   default values are specified so as to make it unnecessary to
   configure any of these variables in many cases.

   For each multicast interface:

   PerformRouterDiscovery
                 A flag indicating whether or not the host is to perform
                 ICMP router discovery on the interface.

                 Default: TRUE

   SolicitationAddress
                 The IP destination address to be used for sending
                 Router Solicitations from the interface.  The only
                 permissible values are the all-routers multicast
                 address, 224.0.0.2, or the limited-broadcast address,
                 255.255.255.255.  (The all-routers address is preferred
                 wherever possible, i.e., on any link where all
                 advertising routers support IP multicast.)




Router Discovery Working Group                                 [Page 12]

RFC 1256             ICMP Router Discovery Messages       September 1991


                 Default: 224.0.0.2 if the host supports IP multicast on
                 the interface, else 255.255.255.255

   The Host Requirements -- Communication Layers RFC [1], Section
   3.3.1.6, specifies that each host implementation must support a
   configurable list of default router addresses.  The purpose of the
   ICMP router discovery messages is to eliminate the need to configure
   that list in hosts attached to multicast links.  On non-multicast
   links, and on multicast links for which ICMP router discovery is not
   (yet) supported by the routers or is administratively disabled, it
   will continue to be necessary to configure the default router list in
   each host.  Each entry in the list contains (at least) the following
   configurable variables:

   RouterAddress
                 An IP address of a default router.

                 Default: (none)

   PreferenceLevel
                 The preferability of the RouterAddress as a default
                 router address, relative to other router addresses on
                 the same subnet.  The Host Requirements RFC does not
                 specify how this value is to be encoded; to allow the
                 preference level to be conveyed in a Router
                 Advertisement or configured by system management, it is
                 here specified that it be encoded as a 32-bit, signed,
                 twos-complement integer, with higher values meaning
                 more preferable.  The minimum value (hex 80000000) is
                 reserved to mean that the address is not to be used as
                 a default router address, i.e., it is to be used only
                 for specific IP destinations, of which the host has
                 been informed by ICMP Redirect or configuration.

                 Default: 0

5.2. Message Validation by Hosts

   A host must silently discard any received Router Advertisement
   messages that do not satisfy the following validity checks:

      - ICMP Checksum is valid.

      - ICMP Code is 0.

      - ICMP Num Addrs is greater than or equal to 1.

      - ICMP Addr Entry Size is greater than or equal to 2.



Router Discovery Working Group                                 [Page 13]

RFC 1256             ICMP Router Discovery Messages       September 1991


      - ICMP length (derived from the IP length) is greater than or
        equal to 8 + (Num Addrs * Addr Entry Size * 4) octets.

   The contents of any additional words of per-address information
   (i.e., other than the Router Address and Preference Level fields),
   and the contents of any octets beyond the first 8 + (Num Addrs * Addr
   Entry Size * 4) octets, are ignored.  Future, backward-compatible
   changes to the protocol may specify additional per-address
   information words, or additional octets at the end of the message;
   backward-incompatible changes may use different Code values.

   An advertisement that passes the validity checks is called a "valid
   advertisement".

   A host must silently discard any received Router Solicitation
   messages.

5.3. Host Behavior

   On any interface on which the host supports IP multicast, the host
   will be a member of the all-systems IP multicast group (224.0.0.1).
   This occurs automatically, as specified in [4]; no explicit action is
   required on the part of the router discovery protocol implementation.

   A host never sends a Router Advertisement message.

   A host silently discards any Router Advertisement message that
   arrives on an interface for which the host's configured
   PerformRouterDiscovery flag is FALSE, and it never sends a Router
   Solicitation on such an interface.

   A host cannot process an advertisement until it has determined its
   own IP address(es) and subnet mask(s) for the interface on which the
   advertisement is received.  (On some links, a host may be able to use
   some combination of BOOTP [3], RARP [5], or ICMP Address Mask
   messages [7] to discover its own address and mask.)  While waiting to
   learn the address and mask of an interface, a host may save any valid
   advertisements received on that interface for later processing; this
   allows router discovery and address/mask discovery to proceed in
   parallel.

   To process an advertisement, a host scans the list of router
   addresses contained in it. It ignores any non-neighboring addresses,
   i.e., addresses that do not match one of the host's own addresses on
   the arrival interface, under the subnet mask associated with that
   address.  For each neighboring address, the host does the following:

      - If the address is not already present in the host's default



Router Discovery Working Group                                 [Page 14]

RFC 1256             ICMP Router Discovery Messages       September 1991


        router list, a new entry is added to the list, containing
        the address along with its accompanying preference level
        and a timer initialized to the Lifetime value from the
        advertisement.

      - If the address is already present in the host's default
        router list as a result of a previously-received
        advertisement, its preference level is updated and its
        timer is reset to the values in the newly-received
        advertisement.

      - If the address is already present in the host's default
        router list as a result of system configuration, no change
        is made to its preference level; there is no timer
        associated with a configured address.  (Note that any
        router addresses acquired from the "Gateway" subfield of
        the vendor extensions field of a BOOTP packet [11] are
        considered to be configured addresses; they are assigned
        the default preference level of zero, and they do not have
        an associated timer.  Note further that any address found
        in the "giaddr" field of a BOOTP packet [3] identifies a
        BOOTP forwarder which is not necessarily an IP router; such
        an address should not be installed in the host's default
        router list.)

   Whenever the timer expires in any entry that was created as a result
   of a received advertisement, that entry is discarded.

   To limit the storage needed for the default router list, a host may
   choose not to store all of the router addresses discovered via
   advertisements.  If so, the host should discard those addresses with
   lower preference levels in favor of those with higher levels.  It is
   desirable to retain more than one default router address in the list
   so that, if the current choice of default router is discovered to be
   down, the host may immediately choose another default router, without
   having to wait for the next advertisement to arrive.

   Any router address advertised with a preference level of hex 80000000
   is not to be used by the host as default router address; such an
   address may be omitted from the default router list, unless its timer
   is being use as a "black-hole" detection mechanism, as discussed in
   Section 4.1.

   It should be understood that preference levels learned from
   advertisements do not affect any of the host's cached route entries.
   For example, if the host has been redirected to use a particular
   router address to reach a specific IP destination, it continues to
   use that router address for that destination, even if it discovers



Router Discovery Working Group                                 [Page 15]

RFC 1256             ICMP Router Discovery Messages       September 1991


   another router address with a higher preference level.  Preference
   levels influence the choice of router only for an IP destination for
   which there is no cached or configured route, or whose cached route
   points to a router that is subsequently discovered to be dead or
   unreachable.

   A host is permitted (but not required) to transmit up to
   MAX_SOLICITATIONS Router Solicitation messages from any of its
   multicast interfaces after any of the following events:

      - The interface is initialized at system startup time.

      - The interface is reinitialized after a temporary interface
        failure or after being temporarily disabled by system
        management.

      - The system changes from being a router to being a host, by
        having its IP forwarding capability turned off by system
        management.

      - The PerformRouterDiscovery flag for the interface is
        changed from FALSE to TRUE by system management.

   The IP destination address of the solicitations is the configured
   SolicitationAddress for the interface.  The IP source address may
   contain zero if the host has not yet determined an address for the
   interface; otherwise it contains one of the interface's addresses.

   If a host does choose to send a solicitation after one of the above
   events, it should delay that transmission for a random amount of time
   between 0 and MAX_SOLICITATION_DELAY.  This serves to alleviate
   congestion when many hosts start up on a link at the same time, such
   as might happen after recovery from a power failure.  (It is
   recommended that hosts include some unique value, such as one of
   their IP or link-layer addresses, in the seed used to initialize
   their pseudo-random number generators.  Although the randomization
   range is specified in units of seconds, the actual randomly-chosen
   value should not be in units of whole seconds, but rather in units of
   the highest available timer resolution.)

   A host may also choose to further postpone its solicitations,
   subsequent to one of the above events, until the first time it needs
   to use a default router.

   Upon receiving a valid advertisement containing at least one
   neighboring address whose preference level is other than hex
   80000000, subsequent to one of the above events, the host must desist
   from sending any solicitations on that interface (even if none have



Router Discovery Working Group                                 [Page 16]

RFC 1256             ICMP Router Discovery Messages       September 1991


   been sent yet), until the next time one of the above events occurs.
   The small number of retransmissions of a solicitation, which are
   permitted if no such advertisement is received, should be sent at
   intervals of SOLICITATION_INTERVAL seconds, without randomization.

6. Protocol Constants

   Router constants:

         MAX_INITIAL_ADVERT_INTERVAL       16 seconds

         MAX_INITIAL_ADVERTISEMENTS        3 transmissions

         MAX_RESPONSE_DELAY                2 seconds

   Host constants:

         MAX_SOLICITATION_DELAY            1 second

         SOLICITATION_INTERVAL             3 seconds

         MAX_SOLICITATIONS                 3 transmissions

   Additional protocol constants are defined with the message formats in
   Section 3, and with the router and host configuration variables in
   Sections 4.1 and 5.1.

   All protocol constants are subject to change in future revisions of
   the protocol.

7. Security Considerations

   This extension of ICMP makes it possible for any system attached to a
   link to masquerade as a default router for hosts attached to that
   link.  Any traffic sent to such an imposter is vulnerable to
   eavesdropping, to denial of forwarding service, and to modification
   by insertion, deletion, or alteration of packets.  It should be noted
   that, on most multicast or broadcast links on which this protocol is
   expected to operate, eavesdropping is already possible by any system
   attached to the link, and the Address Resolution Protocol (ARP) used
   on those links offers a similar opportunity for service denial and
   message stream modification.  For environments where those threats
   are deemed unacceptable, there are configuration variables to disable
   dynamic router discovery by hosts.

   The Router Advertisement message format is defined so as to allow
   additional information to be added to the message in a backward-
   compatible manner.  One possible use of that capability is to add



Router Discovery Working Group                                 [Page 17]

RFC 1256             ICMP Router Discovery Messages       September 1991


   digital signatures or some other form of authentication information
   to the advertisements, to enable hosts to verify their authenticity.
   This is FOR FURTHER STUDY.

References

   [1] Braden, R., Editor, "Requirements for Internet Hosts --
       Communication Layers", RFC 1122, USC/Information Sciences
       Institute, October 1989.

   [2] Braden, R., and J. Postel, "Requirements for Internet Gateways",
       RFC 1009, USC/Information Sciences Institute, June 1987.

   [3] Croft, B, and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
       Stanford and SUN Microsystems, September 1985.

   [4] Deering, S., "Host Extensions for IP Multicasting", RFC 1112,
       Stanford University, August 1989.

   [5] Finlayson, R., Mann, T., Mogul J., and M. Theimer, "A Reverse
       Address Resolution Protocol", RFC 903, Stanford University, June
       1984.

   [6] Mogul, J., "Broadcasting Internet Datagrams", RFC 919, Stanford
       University, October 1984.

   [7] Mogul J., and J. Postel, "Internet Standard Subnetting
       Procedure", RFC 950, USC/Information Sciences Institute, August
       1985.

   [8] Piscitello D., and J. Lawrence, "Transmission of IP datagrams
       over the SMDS Service", RFC 1209, Bell Communications Research,
       March, 1991.

   [9] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       Specification", RFC 791, DARPA, September 1981.

  [10] Postel, J., "Internet Control Message Protocol - DARPA Internet
       Program Protocol Specification", RFC 792, USC/Information
       Sciences Institute, September 1981.

  [11] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1084,
       USC/Information Sciences Institute, December 1988.








Router Discovery Working Group                                 [Page 18]

RFC 1256             ICMP Router Discovery Messages       September 1991


Author's Address

       Stephen E. Deering
       Xerox Palo Alto Research Center
       3333 Coyote Hill Road
       Palo Alto, CA  94304

       Phone: (415) 494-4839

       EMail: deering@xerox.com

       Or send comments to gw-discovery@gregorio.stanford.edu.







































Router Discovery Working Group                                 [Page 19]