File: rfc2080.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 (1066 lines) | stat: -rw-r--r-- 47,532 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






Network Working Group                                          G. Malkin
Request for Comments: 2080                                      Xylogics
Category: Standards Track                                     R. Minnear
                                                        Ipsilon Networks
                                                            January 1997

                             RIPng for IPv6

Status of this Memo

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

Abstract

   This document specifies a routing protocol for an IPv6 internet.  It
   is based on protocols and algorithms currently in wide use in the
   IPv4 Internet.

   This specification represents the minimum change to the Routing
   Information Protocol (RIP), as specified in RFC 1058 [1] and RFC 1723
   [2], necessary for operation over IPv6 [3].

Acknowledgements

   This document is a modified version of RFC 1058, written by Chuck
   Hedrick [1].  The modifications reflect RIP-2 and IPv6 enhancements,
   but the original wording is his.

   We'd like to thank Dennis Ferguson and Thomas Narten for their input.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1   Theoretical Underpinnings  . . . . . . . . . . . . . . . . .  3
   1.2   Limitations of the Protocol  . . . . . . . . . . . . . . . .  3
   2.  Protocol Specification . . . . . . . . . . . . . . . . . . . .  4
   2.1   Message Format . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1.1   Next Hop . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.2   Addressing Considerations  . . . . . . . . . . . . . . . . .  8
   2.3   Timers . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   2.4   Input Processing . . . . . . . . . . . . . . . . . . . . . . 10
   2.4.1   Request Messages . . . . . . . . . . . . . . . . . . . . . 10
   2.4.2   Response Messages  . . . . . . . . . . . . . . . . . . . . 11



Malkin & Minnear            Standards Track                     [Page 1]

RFC 2080                     RIPng for IPv6                 January 1997


   2.5   Output Processing  . . . . . . . . . . . . . . . . . . . . . 14
   2.5.1   Triggered Updates  . . . . . . . . . . . . . . . . . . . . 14
   2.5.2   Generating Response Messages . . . . . . . . . . . . . . . 15
   2.6   Split Horizon  . . . . . . . . . . . . . . . . . . . . . . . 16
   3.  Control Functions  . . . . . . . . . . . . . . . . . . . . . . 17
   4.  Security Considerations. . . . . . . . . . . . . . . . . . . . 18
   References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

1. Introduction

   This memo describes one protocol in a series of routing protocols
   based on the Bellman-Ford (or distance vector) algorithm.  This
   algorithm has been used for routing computations in computer networks
   since the early days of the ARPANET.  The particular packet formats
   and protocol described here are based on the program "routed," which
   is included with the Berkeley distribution of Unix.

   In an international network, such as the Internet, it is very
   unlikely that a single routing protocol will used for the entire
   network.  Rather, the network will be organized as a collection of
   Autonomous Systems (AS), each of which will, in general, be
   administered by a single entity.  Each AS will have its own routing
   technology, which may differ among AS's.  The routing protocol used
   within an AS is referred to as an Interior Gateway Protocol (IGP).  A
   separate protocol, called an Exterior Gateway Protocol (EGP), is used
   to transfer routing information among the AS's.  RIPng was designed
   to work as an IGP in moderate-size AS's.  It is not intended for use
   in more complex environments.  For information on the context into
   which RIP version 1 (RIP-1) is expected to fit, see Braden and Postel
   [6].

   RIPng is one of a class of algorithms known as Distance Vector
   algorithms.  The earliest description of this class of algorithms
   known to the author is in Ford and Fulkerson [8].  Because of this,
   they are sometimes known as Ford-Fulkerson algorithms.  The term
   Bellman-Ford is also used, and derives from the fact that the
   formulation is based on Bellman's equation [4].  The presentation in
   this document is closely based on [5].  This document contains a
   protocol specification.  For an introduction to the mathematics of
   routing algorithms, see [1].  The basic algorithms used by this
   protocol were used in computer routing as early as 1969 in the
   ARPANET.  However, the specific ancestry of this protocol is within
   the Xerox network protocols.  The PUP protocols [7] used the Gateway
   Information Protocol to exchange routing information.  A somewhat
   updated version of this protocol was adopted for the Xerox Network
   Systems (XNS) architecture, with the name Routing Information
   Protocol [9].  Berkeley's routed is largely the same as the Routing



Malkin & Minnear            Standards Track                     [Page 2]

RFC 2080                     RIPng for IPv6                 January 1997


   Information Protocol, with XNS addresses replaced by a more general
   address format capable of handling IPv4 and other types of address,
   and with routing updates limited to one every 30 seconds.  Because of
   this similarity, the term Routing Information Protocol (or just RIP)
   is used to refer to both the XNS protocol and the protocol used by
   routed.

1.1  Theoretical Underpinnings

   An introduction to the theory and math behind Distance Vector
   protocols is provided in [1].  It has not been incorporated in this
   document for the sake of brevity.

1.2  Limitations of the Protocol

   This protocol does not solve every possible routing problem.  As
   mentioned above, it is primarily intended for use as an IGP in
   networks of moderate size.  In addition, the following specific
   limitations are be mentioned:

   - The protocol is limited to networks whose longest path (the
     network's diameter) is 15 hops.  The designers believe that the
     basic protocol design is inappropriate for larger networks.  Note
     that this statement of the limit assumes that a cost of 1 is used
     for each network.  This is the way RIPng is normally configured.
     If the system administrator chooses to use larger costs, the upper
     bound of 15 can easily become a problem.

   - The protocol depends upon "counting to infinity" to resolve certain
     unusual situations (see section 2.2 in [1]).  If the system of
     networks has several hundred networks, and a routing loop was formed
     involving all of them, the resolution of the loop would require
     either much time (if the frequency of routing updates were limited)
     or bandwidth (if updates were sent whenever changes were detected).
     Such a loop would consume a large amount of network bandwidth
     before the loop was corrected.  We believe that in realistic cases,
     this will not be a problem except on slow lines.  Even then, the
     problem will be fairly unusual, since various precautions are taken
     that should prevent these problems in most cases.

   - This protocol uses fixed "metrics" to compare alternative routes.
     It is not appropriate for situations where routes need to be chosen
     based on real-time parameters such a measured delay, reliability,
     or load.  The obvious extensions to allow metrics of this type are
     likely to introduce instabilities of a sort that the protocol is
     not designed to handle.





Malkin & Minnear            Standards Track                     [Page 3]

RFC 2080                     RIPng for IPv6                 January 1997


2. Protocol Specification

   RIPng is intended to allow routers to exchange information for
   computing routes through an IPv6-based network.  RIPng is a distance
   vector protocol, as described in [1].  RIPng should be implemented
   only in routers; IPv6 provides other mechanisms for router discovery
   [10].  Any router that uses RIPng is assumed to have interfaces to
   one or more networks, otherwise it isn't really a router.  These are
   referred to as its directly-connected networks.  The protocol relies
   on access to certain information about each of these networks, the
   most important of which is its metric.  The RIPng metric of a network
   is an integer between 1 and 15, inclusive.  It is set in some manner
   not specified in this protocol; however, given the maximum path limit
   of 15, a value of 1 is usually used.  Implementations should allow
   the system administrator to set the metric of each network.  In
   addition to the metric, each network will have an IPv6 destination
   address prefix and prefix length associated with it.  These are to be
   set by the system administrator in a manner not specified in this
   protocol.

   Each router that implements RIPng is assumed to have a routing table.
   This table has one entry for every destination that is reachable
   throughout the system operating RIPng.  Each entry contains at least
   the following information:

   - The IPv6 prefix of the destination.

   - A metric, which represents the total cost of getting a datagram
     from the router to that destination.  This metric is the sum of the
     costs associated with the networks that would be traversed to get
     to the destination.

   - The IPv6 address of the next router along the path to the
     destination (i.e., the next hop).  If the destination is on one of
     the directly-connected networks, this item is not needed.

   - A flag to indicate that information about the route has changed
     recently.  This will be referred to as the "route change flag."

   - Various timers associated with the route.  See section 2.3 for more
     details on timers.

   The entries for the directly-connected networks are set up by the
   router using information gathered by means not specified in this
   protocol.  The metric for a directly-connected network is set to the
   cost of that network.  As mentioned, 1 is the usual cost.  In that
   case, the RIPng metric reduces to a simple hop-count.  More complex
   metrics may be used when it is desirable to show preference for some



Malkin & Minnear            Standards Track                     [Page 4]

RFC 2080                     RIPng for IPv6                 January 1997


   networks over others (e.g., to indicate of differences in bandwidth
   or reliability).

   Implementors may also choose to allow the system administrator to
   enter additional routes.  These would most likely be routes to hosts
   or networks outside the scope of the routing system.  They are
   referred to as "static routes."  Entries for destinations other than
   these initial ones are added and updated by the algorithms described
   in the following sections.

   In order for the protocol to provide complete information on routing,
   every router in the AS must participate in the protocol.  In cases
   where multiple IGPs are in use, there must be at least one router
   which can leak routing information between the protocols.

2.1  Message Format

   RIPng is a UDP-based protocol.  Each router that uses RIPng has a
   routing process that sends and receives datagrams on UDP port number
   521, the RIPng port.  All communications intended for another
   router's RIPng process are sent to the RIPng port.  All routing
   update messages are sent from the RIPng port.  Unsolicited routing
   update messages have both the source and destination port equal to
   the RIPng port.  Those sent in response to a request are sent to the
   port from which the request came.  Specific queries may be sent from
   ports other than the RIPng port, but they must be directed to the
   RIPng port on the target machine.

   The RIPng packet format is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  command (1)  |  version (1)  |       must be zero (2)        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry 1 (20)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                         ...                                   ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                Route Table Entry N (20)                       ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Malkin & Minnear            Standards Track                     [Page 5]

RFC 2080                     RIPng for IPv6                 January 1997


   where each Route Table Entry (RTE) 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                        IPv6 prefix (16)                       ~
      |                                                               |
      +---------------------------------------------------------------+
      |         route tag (2)         | prefix len (1)|  metric (1)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The maximum number of RTEs is defined below.

   Field sizes are given in octets.  Unless otherwise specified, fields
   contain binary integers, in network byte order, with the most-
   significant octet first (big-endian).  Each tick mark represents one
   bit.

   Every message contains a RIPng header which consists of a command and
   a version number.  This document describes version 1 of the protocol
   (see section 2.4).  The command field is used to specify the purpose
   of this message.  The commands implemented in version 1 are:

   1 - request    A request for the responding system to send all or
                  part of its routing table.

   2 - response   A message containing all or part of the sender's
                  routing table.  This message may be sent in response
                  to a request, or it may be an unsolicited routing
                  update generated by the sender.

   For each of these message types, the remainder of the datagram
   contains a list of RTEs.  Each RTE in this list contains a
   destination prefix, the number of significant bits in the prefix, and
   the cost to reach that destination (metric).

   The destination prefix is the usual 128-bit, IPv6 address prefix
   stored as 16 octets in network byte order.

   The route tag field is an attribute assigned to a route which must be
   preserved and readvertised with a route.  The intended use of the
   route tag is to provide a method of separating "internal" RIPng
   routes (routes for networks within the RIPng routing domain) from
   "external" RIPng routes, which may have been imported from an EGP or
   another IGP.





Malkin & Minnear            Standards Track                     [Page 6]

RFC 2080                     RIPng for IPv6                 January 1997


   Routers supporting protocols other than RIPng should be configurable
   to allow the route tag to be configured for routes imported from
   different sources.  For example, routes imported from an EGP should
   be able to have their route tag either set to an arbitrary value, or
   at least to the number of the Autonomous System from which the routes
   were learned.

   Other uses of the route tag are valid, as long as all routers in the
   RIPng domain use it consistently.

   The prefix length field is the length in bits of the significant part
   of the prefix (a value between 0 and 128 inclusive) starting from the
   left of the prefix.

   The metric field contains a value between 1 and 15 inclusive,
   specifying the current metric for the destination; or the value 16
   (infinity), which indicates that the destination is not reachable.

   The maximum datagram size is limited by the MTU of the medium over
   which the protocol is being used.  Since an unsolicited RIPng update
   is never propagated across a router, there is no danger of an MTU
   mismatch.  The determination of the number of RTEs which may be put
   into a given message is a function of the medium's MTU, the number of
   octets of header information preceeding the RIPng message, the size
   of the RIPng header, and the size of an RTE.  The formula is:

               +-                                                   -+
               | MTU - sizeof(IPv6_hdrs) - UDP_hdrlen - RIPng_hdrlen |
   #RTEs = INT | --------------------------------------------------- |
               |                      RTE_size                       |
               +-                                                   -+

2.1.1  Next Hop

   RIPng provides the ability to specify the immediate next hop IPv6
   address to which packets to a destination specified by a route table
   entry (RTE) should be forwarded in much the same way as RIP-2 [2].
   In RIP-2, each route table entry has a next hop field.  Including a
   next hop field for each RTE in RIPng would nearly double the size of
   the RTE.  Therefore, in RIPng, the next hop is specified by a special
   RTE and applies to all of the address RTEs following the next hop RTE
   until the end of the message or until another next hop RTE is
   encountered.

   A next hop RTE is identified by a value of 0xFF in the metric field
   of an RTE.  The prefix field specifies the IPv6 address of the next
   hop.  The route tag and prefix length in the next hop RTE must be set
   to zero on sending and ignored on receiption.



Malkin & Minnear            Standards Track                     [Page 7]

RFC 2080                     RIPng for IPv6                 January 1997


   The next hop Route Table Entry (RTE) 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                    IPv6 next hop address (16)                 ~
   |                                                               |
   +---------------------------------------------------------------+
   |        must be zero (2)       |must be zero(1)|     0xFF      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Specifying a value of 0:0:0:0:0:0:0:0 in the prefix field of a next
   hop RTE indicates that the next hop address should be the originator
   of the RIPng advertisement.  An address specified as a next hop must
   be a link-local address.

   The purpose of the next hop RTE is to eliminate packets being routed
   through extra hops in the system.  It is particularly useful when
   RIPng is not being run on all of the routers on a network.  Note that
   next hop RTE is "advisory".  That is, if the provided information is
   ignored, a possibly sub-optimal, but absolutely valid, route may be
   taken.  If the received next hop address is not a link-local address,
   it should be treated as 0:0:0:0:0:0:0:0.

2.2  Addressing Considerations

   The distinction between network, subnet and host routes does not need
   to be made for RIPng because an IPv6 address prefix is unambiguous.

   Any prefix with a prefix length of zero is used to designate a
   default route.  It is suggested that the prefix 0:0:0:0:0:0:0:0 be
   used when specifying the default route, though the prefix is
   essentially ignored.  A default route is used when it is not
   convenient to list every possible network in the RIPng updates, and
   when one or more routers in the system are prepared to handle traffic
   to the networks that are not explicitly listed.  These "default
   routers" use the default route as a path for all datagrams for which
   they have no explicit route.  The decision as to how a router becomes
   a default router (i.e., how a default route entry is created) is left
   to the implementor.  In general, the system administrator will be
   provided with a way to specify which routers should create and
   advertise default route entries.  If this mechanism is used, the
   implementation should allow the network administrator to choose the
   metric associated with the default route advertisement.  This will
   make it possible to establish a precedence amoung multiple default
   routers.  The default route entries are handled by RIPng in exactly
   the same manner as any other destination prefix.  System



Malkin & Minnear            Standards Track                     [Page 8]

RFC 2080                     RIPng for IPv6                 January 1997


   administrators should take care to make sure that default routes do
   not propagate further than is intended.  Generally, each AS has its
   own preferred default router.  Therefore, default routes should
   generally not leave the boundary of an AS.  The mechanisms for
   enforcing this restriction are not specified in this document.

2.3  Timers

   This section describes all events that are triggered by timers.

   Every 30 seconds, the RIPng process is awakened to send an
   unsolicited Response message, containing the complete routing table
   (see section 2.6 on Split Horizon), to every neighboring router.
   When there are many routers on a single network, there is a tendency
   for them to synchronize with each other such that they all issue
   updates at the same time.  This can happen whenever the 30 second
   timer is affected by the processing load on the system.  It is
   undesirable for the update messages to become synchronized, since it
   can lead to unnecessary collisions on broadcast networks (see [13]
   for more details).  Therefore, implementations are required to take
   one of two precautions:

   - The 30-second updates are triggered by a clock whose rate is not
     affected by system load or the time required to service the
     previous update timer.

   - The 30-second timer is offset by a small random time (+/- 0 to 15
     seconds) each time it is set.  The offset is derived from: 0.5 *
     the update period (i.e. 30).

   There are two timers associated with each route, a "timeout" and a
   "garbage-collection time."  Upon expiration of the timeout, the route
   is no longer valid; however, it is retained in the routing table for
   a short time so that neighbors can be notified that the route has
   been dropped.  Upon expiration of the garbage-collection timer, the
   route is finally removed from the routing table.

   The timeout is initialized when a route is established, and any time
   an update message is received for the route.  If 180 seconds elapse
   from the last time the timeout was initialized, the route is
   considered to have expired, and the deletion process described below
   begins for that route.









Malkin & Minnear            Standards Track                     [Page 9]

RFC 2080                     RIPng for IPv6                 January 1997


   Deletions can occur for one of two reasons: the timeout expires, or
   the metric is set to 16 because of an update received from the
   current router (see section 2.4.2 for a discussion of processing
   updates from other routers).  In either case, the following events
   happen:

   - The garbage-collection timer is set for 120 seconds.

   - The metric for the route is set to 16 (infinity).  This causes the
     route to be removed from service.

   - The route change flag is to indicate that this entry has been
     changed.

   - The output process is signalled to trigger a response.

   Until the garbage-collection timer expires, the route is included in
   all updates sent by this router.  When the garbage-collection timer
   expires, the route is deleted from the routing table.

   Should a new route to this network be established while the garbage-
   collection timer is running, the new route will replace the one that
   is about to be deleted.  In this case the garbage-collection timer
   must be cleared.

   Triggered updates also use a small timer; however, this is best
   described in section 2.5.1.

2.4  Input Processing

   This section will describe the handling of datagrams received on the
   RIPng port.  Processing will depend upon the value in the command
   field.  Version 1 supports only two commands: Request and Response.

2.4.1  Request Messages

   A Request is used to ask for a response containing all or part of a
   router's routing table.  Normally, Requests are sent as multicasts,
   from the RIPng port, by routers which have just come up and are
   seeking to fill in their routing tables as quickly as possible.
   However, there may be situations (e.g., router monitoring) where the
   routing table of only a single router is needed.  In this case, the
   Request should be sent directly to that router from a UDP port other
   than the RIPng port.  If such a Request is received, the router
   responds directly to the requestor's address and port with a globally
   valid source address since the requestor may not reside on the
   directly attached network.




Malkin & Minnear            Standards Track                    [Page 10]

RFC 2080                     RIPng for IPv6                 January 1997


   The Request is processed entry by entry.  If there are no entries, no
   response is given.  There is one special case.  If there is exactly
   one entry in the request, and it has a destination prefix of zero, a
   prefix length of zero, and a metric of infinity (i.e., 16), then this
   is a request to send the entire routing table.  In that case, a call
   is made to the output process to send the routing table to the
   requesting address/port.  Except for this special case, processing is
   quite simple.  Examine the list of RTEs in the Request one by one.
   For each entry, look up the destination in the router's routing
   database and, if there is a route, put that route's metric in the
   metric field of the RTE.  If there is no explicit route to the
   specified destination, put infinity in the metric field.  Once all
   the entries have been filled in, change the command from Request to
   Response and send the datagram back to the requestor.

   Note that there is a difference in metric handling for specific and
   whole-table requests.  If the request is for a complete routing
   table, normal output processing is done, including Split Horizon (see
   section 2.6 on Split Horizon).  If the request is for specific
   entries, they are looked up in the routing table and the information
   is returned as is; no Split Horizon processing is done.  The reason
   for this distinction is the expectation that these requests are
   likely to be used for different purposes.  When a router first comes
   up, it multicasts a Request on every connected network asking for a
   complete routing table.  It is assumed that these complete routing
   tables are to be used to update the requestor's routing table.  For
   this reason, Split Horizon must be done.  It is further assumed that
   a Request for specific networks is made only by diagnostic software,
   and is not used for routing.  In this case, the requester would want
   to know the exact contents of the routing table and would not want
   any information hidden or modified.

2.4.2  Response Messages

   A Response can be received for one of several different reasons:

   - response to a specific query
   - regular update (unsolicited response)
   - triggered update caused by a route change

   Processing is the same no matter why the Response was generated.

   Because processing of a Response may update the router's routing
   table, the Response must be checked carefully for validity.  The
   Response must be ignored if it is not from the RIPng port.  The
   datagram's IPv6 source address should be checked to see whether the
   datagram is from a valid neighbor; the source of the datagram must be
   a link-local address.  It is also worth checking to see whether the



Malkin & Minnear            Standards Track                    [Page 11]

RFC 2080                     RIPng for IPv6                 January 1997


   response is from one of the router's own addresses.  Interfaces on
   broadcast networks may receive copies of their own multicasts
   immediately.  If a router processes its own output as new input,
   confusion is likely, and such datagrams must be ignored.  As an
   additional check, periodic advertisements must have their hop counts
   set to 255, and inbound, multicast packets sent from the RIPng port
   (i.e. periodic advertisement or triggered update packets) must be
   examined to ensure that the hop count is 255.  This absolutely
   guarantees that a packet is from a neighbor, because any intermediate
   node would have decremented the hop count.  Queries and their
   responses may still cross intermediate nodes and therefore do not
   require the hop count test to be done.

   Once the datagram as a whole has been validated, process the RTEs in
   the Response one by one.  Again, start by doing validation.
   Incorrect metrics and other format errors usually indicate
   misbehaving neighbors and should probably be brought to the
   administrator's attention.  For example, if the metric is greater
   than infinity, ignore the entry but log the event.  The basic
   validation tests are:

   - is the destination prefix valid (e.g., not a multicast prefix and
     not a link-local address)  A link-local address should never be
     present in an RTE.
   - is the prefix length valid (i.e., between 0 and 128, inclusive)
   - is the metric valid (i.e., between 1 and 16, inclusive)

   If any check fails, ignore that entry and proceed to the next.
   Again, logging the error is probably a good idea.

   Once the entry has been validated, update the metric by adding the
   cost of the network on which the message arrived.  If the result is
   greater than infinity, use infinity.  That is,

                  metric = MIN (metric + cost, infinity)

   Now, check to see whether there is already an explicit route for the
   destination prefix.  If there is no such route, add this route to the
   routing table, unless the metric is infinity (there is no point in
   adding a route which unusable).  Adding a route to the routing table
   consists of:

   - Setting the destination prefix and length to those in the RTE.

   - Setting the metric to the newly calculated metric (as described
     above).





Malkin & Minnear            Standards Track                    [Page 12]

RFC 2080                     RIPng for IPv6                 January 1997


   - Set the next hop address to be the address of the router from which
     the datagram came or the next hop address specified by a next hop
     RTE.

   - Initialize the timeout for the route.  If the garbage-collection
     timer is running for this route, stop it (see section 2.3 for a
     discussion of the timers).

   - Set the route change flag.

   - Signal the output process to trigger an update (see section 2.5).

   If there is an existing route, compare the next hop address to the
   address of the router from which the datagram came.  If this datagram
   is from the same router as the existing route, reinitialize the
   timeout.  Next, compare the metrics.  If the datagram is from the
   same router as the existing route, and the new metric is different
   than the old one; or, if the new metric is lower than the old one; do
   the following actions:

   - Adopt the route from the datagram.  That is, put the new metric in,
     and adjust the next hop address (if necessary).

   - Set the route change flag and signal the output process to trigger
     an update.

   - If the new metric is infinity, start the deletion process
     (described above); otherwise, re-initialize the timeout.

   If the new metric is infinity, the deletion process begins for the
   route, which is no longer used for routing packets.  Note that the
   deletion process is started only when the metric is first set to
   infinity.  If the metric was already infinity, then a new deletion
   process is not started.

   If the new metric is the same as the old one, it is simplest to do
   nothing further (beyond reinitializing the timeout, as specified
   above); but, there is a heuristic which could be applied.  Normally,
   it is senseless to replace a route if the new route has the same
   metric as the existing route; this would cause the route to bounce
   back and forth, which would generate an intolerable number of
   triggered updates.  However, if the existing route is showing signs
   of timing out, it may be better to switch to an equally-good
   alternative route immediately, rather than waiting for the timeout to
   happen.  Therefore, if the new metric is the same as the old one,
   examine the timeout for the existing route.  If it is at least
   halfway to the expiration point, switch to the new route.  This
   heuristic is optional, but highly recommended.



Malkin & Minnear            Standards Track                    [Page 13]

RFC 2080                     RIPng for IPv6                 January 1997


   Any entry that fails these tests is ignored, as it is no better than
   the current route.

2.5  Output Processing

   This section describes the processing used to create response
   messages that contain all or part of the routing table.  This
   processing may be triggered in any of the following ways:

   - By input processing, when a Request is received.  In this case, the
     Response is sent to only one destination (i.e. the unicast address
     of the requestor).

   - By the regular routing update.  Every 30 seconds, a Response
     containing the whole routing table is sent to every neighboring
     router.

   - By triggered updates.  Whenever the metric for a route is changed,
     an update is triggered.

   The special processing required for a Request is described in section
   2.4.1.

   When a Response is to be sent to all neighbors (i.e., a regular or
   triggered update), a Response message is multicast to the multicast
   group FF02::9, the all-rip-routers multicast group, on all connected
   networks that support broadcasting or are point-to-point links. RIPng
   handles point-to-point links just like multicast links as
   multicasting can be trivially provided on such links.  Thus, one
   Response is prepared for each directly-connected network, and sent to
   the all-rip-routers multicast group.  In most cases, this reaches all
   neighboring routers.  However, there are some cases where this may
   not be good enough. This may involve a network that is not a
   broadcast network (e.g., the ARPANET), or a situation involving dumb
   routers.  In such cases, it may be necessary to specify an actual
   list of neighboring routers and send a datagram to each one
   explicitly.  It is left to the implementor to determine whether such
   a mechanism is needed, and to define how the list is specified.

2.5.1  Triggered Updates

   Triggered updates require special handling for two reasons.  First,
   experience shows that triggered updates can cause excessive loads on
   networks with limited capacity or networks with many routers on them.
   Therefore, the protocol requires that implementors include provisions
   to limit the frequency of triggered updates.  After a triggered
   update is sent, a timer should be set for a random interval between 1
   and 5 seconds.  If other changes that would trigger updates occur



Malkin & Minnear            Standards Track                    [Page 14]

RFC 2080                     RIPng for IPv6                 January 1997


   before the timer expires, a single update is triggered when the timer
   expires.  The timer is then reset to another random value between 1
   and 5 seconds.  Triggered updates may be suppressed if a regular
   update is due by the time the triggered update would be sent.

   Second, triggered updates do not need to include the entire routing
   table.  In principle, only those routes which have changed need to be
   included.  Therefore messages generated as part of a triggered update
   must include at least those routes that have their route change flag
   set.  They may include additional routes, at the discretion of the
   implementor; however, sending complete routing updates is strongly
   discouraged.  When a triggered update is processed, messages should
   be generated for every directly-connected network.  Split Horizon
   processing is done when generating triggered updates as well as
   normal updates (see section 2.6).  If, after Split Horizon processing
   for a given network, a changed route will appear unchanged on that
   network (e.g., it appears with an infinite metric), the route need
   not be sent.  If no routes need be sent on that network, the update
   may be omitted.  Once all of the triggered updates have been
   generated, the route change flags should be cleared.

   If input processing is allowed while output is being generated,
   appropriate interlocking must be done.  The route change flags should
   not be changed as a result of processing input while a triggered
   update message is being generated.

   The only difference between a triggered update and other update
   messages is the possible omission of routes that have not changed.
   The remaining mechanisms, described in the next section, must be
   applied to all updates.

2.5.2  Generating Response Messages

   This section describes how a Response message is generated for a
   particular directly-connected network:

   The IPv6 source address must be a link-local address of the possible
   addresses of the sending router's interface, except when replying to
   a unicast Request Message from a port other than the RIPng port.  In
   the latter case, the source address must be a globaly valid address.
   In the former case, it is important to use a link-local address
   because the source address is put into routing tables (as the next
   hop) in the routers which receive this Response.  If an incorrect
   source address is used, other routers may be unable to route
   datagrams.  Sometimes routers are set up with multiple IPv6 addresses
   on a single physical interface.  Normally, this means that several
   logical IPv6 networks are being carried over one physical medium.  It
   is possible that a router may have multiple link-local addresses for



Malkin & Minnear            Standards Track                    [Page 15]

RFC 2080                     RIPng for IPv6                 January 1997


   a single interface. In this case, the router must only originate a
   single Response message with a source address of the designated
   link-local address for a given interface.  The choice of which link-
   local address to use should only change when the current choice is no
   longer valid.  This is necessary because nodes receiving Response
   messages use the source address to identify the sender.  If multiple
   packets from the same router contain different source addresses,
   nodes will assume they come from different routers, leading to
   undesirable behavior.

   Set the version number to the current version of RIPng.  The version
   described in this document is version 1.  Set the command to
   Response.  Set the bytes labeled "must be zero" to zero.  Start
   filling in RTEs.  Recall that the maximum datagram size is limited by
   the network's MTU.  When there is no more space in the datagram, send
   the current Response and start a new one.

   To fill in the RTEs, examine each route in the routing table.  Routes
   to link-local addresses must never be included in an RTE.  If a
   triggered update is being generated, only entries whose route change
   flags are set need be included.  If, after Split Horizon processing,
   the route should not be included, skip it.  If the route is to be
   included, then the destination prefix, prefix length, and metric are
   put into the RTE.  The route tag is filled in as defined in section
   2.1.  Routes must be included in the datagram even if their metrics
   are infinite.

2.6  Split Horizon

   Split Horizon is a algorithm for avoiding problems caused by
   including routes in updates sent to the gateway from which they were
   learned.  The basic split horizon algorithm omits routes learned from
   one neighbor in updates sent to that neighbor.  In the case of a
   broadcast network, all routes learned from any neighbor on that
   network are omitted from updates sent on that network.

   Split Horizon with Poisoned Reverse (more simply, Poison Reverse)
   does include such routes in updates, but sets their metrics to
   infinity.  In effect, advertising the fact that there routes are not
   reachable.  This is the preferred method of operation; however,
   implementations should provide a per-interface control allowing no
   horizoning, split horizoning, and poisoned reverse to be selected.

   For a theoretical discussion of Split Horizon and Poison Reverse, and
   why they are needed, see section 2.1.1 of [1].






Malkin & Minnear            Standards Track                    [Page 16]

RFC 2080                     RIPng for IPv6                 January 1997


3. Control Functions

   This section describes administrative controls.  These are not part
   of the protocol per se; however, experience with existing networks
   suggests that they are important.  Because they are not a necessary
   part of the protocol, they are considered optional.  However, it is
   strongly recommend that at least some of them be included in every
   implementation.  These controls are intended primarily to allow RIPng
   to be connected to networks whose routing may be unstable or subject
   to errors.  Here are some examples:

   - It is sometimes desirable to restrict the routers from which
     updates will be accepted, or to which updates will be sent.  This
     is usually done for administrative, routing policy reasons.

   - A number of sites limit the set of networks that they allow in
     Response messages.  Organization A may have a connection to
     organization B that they use for direct communication.  For security
     or performance reasons A may not be willing to give other
     organizations access to that connection.  In such a case, A should
     not include B's networks in updates that A sends to third parties.

   Here are some typical controls.  Note, however, that the RIPng
   protocol does not require these or any other controls.

   - A neighbor list which allows the network administrator to be able
     to define a list of neighbors for each router.  A router would
     accept response messages only from routers on its list of
     neighbors.  A similar list for target routers should also be
     available to the administrator.  By default, no restrictions are
     defined.

   - A filter for specific destinations would permit the network admin-
     istrator to be able to specify a list of destination prefixes to
     allow or disallow.  The list would be associated with a particular
     interface in the incoming and/or outgoing directions.  Only allowed
     networks would be mentioned in Response messages going out or
     processed in Response messages coming in.  If a list of allowed
     prefixes is specified, all other prefixes are disallowed.  If a list
     of disallowed prefixes is specified, all other prefixes are
     allowed.  By default, no filters are applied.










Malkin & Minnear            Standards Track                    [Page 17]

RFC 2080                     RIPng for IPv6                 January 1997


4. Security Considerations

   Since RIPng runs over IPv6, RIPng relies on the IP Authentication
   Header (see [11]) and the IP Encapsulating Security Payload (see
   [12]) to ensure integrity and authentication/confidentiality of
   routing exchanges.

References

   [1] Hedrick, C., "Routing Information Protocol", RFC 1058, Rutgers
       University, June 1988.

   [2] Malkin, G., "RIP Version 2 - Carrying Additional Information",
       RFC 1723, Xylogics, Inc., November, 1994.

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

   [4] Bellman, R., "Dynamic Programming", Princeton University
       Press, Princeton, N.J., 1957.

   [5] Bertsekas, D. P., and Gallaher, R. G., "Data Networks", Prentice-
       Hall, Englewood Cliffs, N.J., 1987.

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

   [7] Boggs, D. R., Shoch, J. F., Taft, E. A., and Metcalfe, R. M.,
       "Pup: An Internetwork Architecture", IEEE Transactions on Commu-
       nications, April 1980.

   [8] Ford, L. R. Jr., and Fulkerson, D. R., "Flows in Networks",
       Princeton University Press, Princeton, N.J., 1962.

   [9] Xerox Corp., "Internet Transport Protocols", Xerox System Inte-
       gration Standard XSIS 028112, December 1981.

   [10] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
        for IP Version 6 (IPv6)", RFC 1970, August 1996.

   [11] Atkinson, R., "IP Authentication Header", RFC 1826
        Naval Research Laboratory, August 1995.









Malkin & Minnear            Standards Track                    [Page 18]

RFC 2080                     RIPng for IPv6                 January 1997


   [12] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
        RFC 1827, Naval Research Laboratory, August 1995.

   [13] Floyd, S., and Jacobson, V., "The Synchronization of Periodic
        Routing Messages", Proceedings of ACM SIGCOMM '93, September
        1993.

Authors' Addresses

   Gary Scott Malkin
   Xylogics, Inc.
   53 Third Avenue
   Burlington, MA 01803

   Phone:  (617) 272-8140
   EMail:  gmalkin@Xylogics.COM


   Robert E. Minnear
   Ipsilon Networks, Inc.
   2191 E. Bayshore Road, Suite 100
   Palo Alto, CA 94303

   Phone:  (415) 846-4614
   EMail:  minnear@ipsilon.com


























Malkin & Minnear            Standards Track                    [Page 19]