RFC 2080

RIPng for IPv6

📅 published January 1997, from ietf

RFC 2080: RIPng for IPv6 🎀

Okay bestie, this is the RIPng spec, and it's giving distance-vector royalty ✨ Here are the title block facts first:

  • RFC number: 2080
  • Title: RIPng for IPv6
  • Authors: G. Malkin (Xylogics) and R. Minnear (Ipsilon Networks)
  • Category: Standards Track
  • Date: January 1997
  • Obsoletes / Updates: nothing is listed in the header, so it doesn't obsolete or update anything 🫶

Status of This Memo 📋

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Abstract 🦋

So this document describes a routing protocol for an IPv6 internet. It's built on protocols and algorithms that are already widely used in the IPv4 Internet, so nothing here is totally new territory 💅

It's also the minimum change to the Routing Information Protocol (RIP) from RFC 1058 [1] and RFC 1723 [2] that you need to run over IPv6 [3]. Minimum change, maximum slay ✨

Acknowledgements 🙏

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

Also, the authors want 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
   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. That algorithm has been doing routing computations in computer networks since the early days of the ARPANET, so it's a true OG 👑

The particular packet formats and protocol here are based on the program "routed," which ships with the Berkeley distribution of Unix 🍓

In an international network like the Internet, it's super unlikely that a single routing protocol gets used for the whole thing. Instead, the network is organized as a collection of Autonomous Systems (AS), and each one is usually run by a single entity. Each AS can have its own routing technology, and those can differ between AS's. The routing protocol used inside an AS is called an Interior Gateway Protocol (IGP). A separate one, the Exterior Gateway Protocol (EGP), moves routing info between AS's 🧚

RIPng was designed to work as an IGP in moderate-size AS's. It is not intended for more complex environments, so don't try to force it there 🙈 For info on the context RIP version 1 (RIP-1) is expected to fit into, see Braden and Postel [6].

RIPng is one of a class of algorithms known as Distance Vector algorithms. The earliest description of this class that the author knows of is in Ford and Fulkerson [8], which is why they're sometimes called Ford-Fulkerson algorithms. The term Bellman-Ford is also used, since 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 intro to the math behind routing algorithms, see [1] 🤓

The basic algorithms this protocol uses were already in computer routing by 1969 in the ARPANET. The specific ancestry of this protocol, though, is in the Xerox network protocols. The PUP protocols [7] used the Gateway Information Protocol to swap routing info. A somewhat updated version of that was adopted for the Xerox Network Systems (XNS) architecture, under the name Routing Information Protocol [9] ✨

Berkeley's routed is largely the same as the Routing Information Protocol. The XNS addresses got replaced with a more general address format that can handle IPv4 and other address types, and routing updates are limited to one every 30 seconds. Because the two are so similar, 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 🧠

The theory and math behind Distance Vector protocols is covered in [1]. It isn't included in this document, for the sake of brevity 📚

1.2 Limitations of the Protocol 🚧

Real talk: this protocol doesn't solve every possible routing problem 😭 As mentioned above, it's mainly meant to be an IGP in networks of moderate size. On top of that, these specific limitations are worth knowing about:

  • The protocol is limited to networks whose longest path (the network's diameter) is 15 hops. The designers believe the basic protocol design is inappropriate for larger networks. This limit assumes a cost of 1 is used for each network, which is how RIPng is normally configured. If the system administrator picks larger costs, the upper bound of 15 can easily become a problem 💀
  • The protocol depends on "counting to infinity" to resolve certain unusual situations (see section 2.2 in [1]). If the system has several hundred networks and a routing loop forms involving all of them, sorting out the loop would take either a lot of time (if routing update frequency is limited) or a lot of bandwidth (if updates get sent whenever changes are detected). Such a loop would eat a large chunk of network bandwidth before it's corrected. The authors believe that in realistic cases this won't be a problem except on slow lines. Even then it should be fairly unusual, since various precautions are taken that should prevent these problems in most cases 🔥
  • The protocol uses fixed "metrics" to compare alternative routes. It isn't appropriate where routes need to be chosen based on real-time parameters such as measured delay, reliability, or load. The obvious extensions that would allow these kinds of metrics are likely to introduce instabilities that the protocol isn't designed to handle 🙅‍♀️

2. Protocol Specification 💅

RIPng is meant to let routers exchange info for computing routes through an IPv6-based network. It's a distance vector protocol, as described in [1]. RIPng should be implemented only in routers, since 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 called its directly-connected networks. The protocol relies on access to certain info about each of these networks, the most important being its metric.

The RIPng metric of a network is an integer between 1 and 15, inclusive. It gets set in some manner this protocol doesn't specify. 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. Each network also has an IPv6 destination address prefix and prefix length associated with it. The system administrator sets these in a manner this protocol doesn't specify either 🎀

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 running RIPng. Each entry contains at least the following:

  • The IPv6 prefix of the destination.
  • A metric, which is the total cost of getting a datagram from the router to that destination. It's the sum of the costs of the networks that would be traversed to get there 🧮
  • The IPv6 address of the next router along the path to the destination (the next hop). If the destination is on one of the directly-connected networks, this item isn't needed.
  • A flag that shows the route's info has changed recently. It's called the "route change flag" 🚩
  • Various timers associated with the route. See section 2.3 for more details on timers ⏰

Entries for the directly-connected networks are set up by the router, using info gathered by means this protocol doesn't specify. The metric for a directly-connected network is set to that network's cost. As mentioned, 1 is the usual cost, and in that case the RIPng metric reduces to a simple hop-count 🦋 More complex metrics can be used when you want to show preference for some networks over others, like to indicate differences in bandwidth or reliability.

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

For the protocol to give complete routing info, every router in the AS must participate in the protocol. Where multiple IGPs are in use, there has to be at least one router that can leak routing info between the protocols. It's the bridge bestie that keeps everyone in the loop 🫶

Part 1 of 5 done! Part 2 is coming right up, so stay tuned 💜

2.1. Message Format ✨

okay so RIPng is a UDP-based protocol 🦋 every router running RIPng has a routing process that sends and receives datagrams on UDP port 521, which is the RIPng port. anything meant for another router's RIPng process gets sent to that RIPng port, and all routing update messages get sent from the RIPng port too. 💅 unsolicited updates have the RIPng port as both source AND destination, but the ones sent in response to a request go back to whatever port the request came from. specific queries can come from other ports, but they have to be aimed at the RIPng port on the target machine. no cap, this is so organized 🎀

the RIPng packet format is giving:

    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)                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where each Route Table Entry (RTE) has this 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 hold binary integers in network byte order, with the most-significant octet first (big-endian). each tick mark in the diagrams is one bit 🌸

every message has a RIPng header made of a command and a version number. this document describes version 1 of the protocol (see section 2.4) ✨. the command field says what the message is for, and version 1 implements these commands:

  • 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. it can be sent in response to a request, or it can be an unsolicited routing update the sender generated itself.

for both message types, the rest of the datagram is a list of RTEs. each RTE carries a destination prefix, the number of significant bits in that prefix, and the cost to reach that destination (the metric) 💜

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

The route tag is an attribute assigned to a route, and it has to be preserved and readvertised along with the route. 😭 The whole point is to separate "internal" RIPng routes (the ones for networks inside the RIPng routing domain) from "external" RIPng routes, which might have been imported from an EGP or another IGP 🫶

routers that support protocols other than RIPng should be configurable so the route tag can be set for routes imported from different sources. for example, routes imported from an EGP should be able to have their route tag set to either an arbitrary value, or at least to the number of the Autonomous System those routes were learned from 🍓

other uses of the route tag are valid too, as long as every router in the RIPng domain uses it consistently 🌈

the prefix length field is the length in bits of the significant part of the prefix, counting from the left. it's a value between 0 and 128 inclusive ✨

the metric field holds a value between 1 and 15 inclusive, which is the current metric for that destination. it can also be the value 16 (infinity), meaning the destination is not reachable 💀

the maximum datagram size is limited by the MTU of the medium the protocol is running over. since an unsolicited RIPng update is never propagated across a router, there's no danger of an MTU mismatch 🙈 how many RTEs fit in one message depends on the medium's MTU, the number of octets of header information before 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 lets you specify the immediate next hop IPv6 address that packets for a destination in an RTE should be forwarded to, kind of like RIP-2 [2] does. but in RIP-2 every route table entry has its own next hop field, and adding one to every RTE in RIPng would nearly double the size of the RTE 😭 so instead, RIPng uses a special RTE for the next hop. it applies to all the address RTEs after it, until the end of the message or until another next hop RTE shows up 💖

a next hop RTE is identified by the value 0xFF in the metric field of an RTE. the prefix field holds the IPv6 address of the next hop. the route tag and prefix length in a next hop RTE must be set to zero when sending, and ignored when receiving 🎀

the next hop Route Table Entry (RTE) has this 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 0:0:0:0:0:0:0:0 in the prefix field of a next hop RTE means the next hop address should be the originator of the RIPng advertisement 🌸 and an address specified as a next hop must be a link-local address.

the whole purpose of the next hop RTE is to stop packets from taking extra hops through the system 🧚 it's especially handy when RIPng isn't running on every router on a network. note that the next hop RTE is "advisory" 💅 meaning, if the info gets ignored, a possibly sub-optimal, but absolutely valid, route may be taken instead. and 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 difference between network, subnet and host routes doesn't need to be made for RIPng, because an IPv6 address prefix is unambiguous. main character energy, no notes 👑

any prefix with a prefix length of zero is used to designate a default route. it's 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 gets used when it isn't convenient to list every possible network in the RIPng updates, and when one or more routers in the system are ready to handle traffic to the networks that aren't explicitly listed. these "default routers" use the default route as the path for every datagram they have no explicit route for 🌈

how a router becomes a default router (aka how a default route entry gets created) is left up to the implementor. generally, the system administrator will be given a way to pick which routers should create and advertise default route entries. if that mechanism is used, the implementation should let the network administrator choose the metric attached to the default route advertisement, so you can set up a precedence among multiple default routers ✨ default route entries are handled by RIPng in exactly the same manner as any other destination prefix.

system administrators should take care to make sure default routes don't propagate further than intended 🚨 generally, each AS has its own preferred default router, so default routes should generally not leave the boundary of an AS. the mechanisms for enforcing this restriction aren't specified in this document 💀

2.3. Timers ⏰

okay so this section is all about the stuff that happens when a timer goes off 🕰️✨

Every 30 seconds, the RIPng process wakes up and sends an unsolicited Response message with the complete routing table (see section 2.6 on Split Horizon) to every neighboring router 📬 Now here's the tea 🫖: when there are lots of routers on one network, they can start syncing up so they all send updates at the exact same moment 😭. That happens whenever system load messes with the 30 second timer. It's undesirable because synced-up updates cause unnecessary collisions on broadcast networks (see [13] for more details) 💀. So implementations are required to take one of these two precautions 🫶:

  • The 30-second updates are triggered by a clock whose rate isn't affected by system load or by the time it takes to handle the previous update timer 🦋.
  • The 30-second timer gets offset by a small random time (+/- 0 to 15 seconds) every time it's set 🎲. The offset is derived from: 0.5 * the update period (i.e. 30).

Each route has two timers: a "timeout" and a "garbage-collection time" 🗑️. When the timeout expires, the route is no longer valid, but it hangs around in the routing table for a little while so neighbors can be told it's been dropped 👀. When the garbage-collection timer expires, the route is finally removed from the routing table 💅.

The timeout gets initialized when a route is established and any time an update message comes in for that route ⏱️. If 180 seconds pass since the timeout was last initialized, the route is considered expired and the deletion process (described below) starts for it 🥀.

Deletions can happen for one of two reasons: the timeout expires, or the metric gets set to 16 because of an update from the current router (see section 2.4.2 for how updates from other routers are processed) 🙈. Either way, these things happen:

  • The garbage-collection timer is set for 120 seconds ⏳.
  • The metric for the route is set to 16 (infinity), which takes the route out of service 🚫.
  • The route change flag is set to indicate that this entry has been changed 🚩.
  • The output process gets signalled to trigger a response 📣.

Until the garbage-collection timer expires, the route is still included in all updates this router sends 🎀. Once that timer expires, the route is deleted from the routing table, bye bye 👋.

If a new route to this network gets established while the garbage-collection timer is running, the new route replaces the one that's about to be deleted 🔄. In that case the garbage-collection timer must be cleared ✨.

Triggered updates also use a small timer, but that one's better explained in section 2.5.1 🧚.

2.4. Input Processing 📥

This section covers how datagrams that arrive on the RIPng port get handled 💌. What happens depends on the value in the command field 🔍. Version 1 only supports 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 🗺️. Usually, Requests get sent as multicasts from the RIPng port by routers that just came up and want to fill in their routing tables ASAP 🏃‍♀️💨. But sometimes only one router's routing table is needed, like with router monitoring 🔬. In that case, the Request should be sent directly to that router from a UDP port other than the RIPng port 🎯. When a Request like that arrives, the router responds directly to the requestor's address and port, using a globally valid source address, since the requestor might not be on the directly attached network 🌍.

The Request is processed entry by entry 📝. If there are no entries, no response is given 🙅‍♀️. There's one special case 🌟: if there's exactly one entry, and it has a destination prefix of zero, a prefix length of zero, and a metric of infinity (i.e., 16), then it's a request for the entire routing table 🫧. In that case, the output process is called to send the routing table to the requesting address/port 📤.

Apart from that special case, it's pretty simple 💖. Go through the RTEs in the Request one at a time. For each one, look up the destination in the router's routing database. If there's a route, put that route's metric in the metric field of the RTE. If there's no explicit route to the destination, put infinity in the metric field ♾️. Once every entry is filled in, change the command from Request to Response and send the datagram back to the requestor 💅.

Now here's the important bit 👑: metric handling is different for specific requests and whole-table requests. If the request is for a complete routing table, normal output processing happens, including Split Horizon (see section 2.6 on Split Horizon) 🌗. If the request is for specific entries, those get looked up in the routing table and the info is returned as-is, with no Split Horizon processing 🫣. The reason is that these requests are likely used for different purposes 🎭. When a router first comes up, it multicasts a Request on every connected network asking for a complete routing table, and those tables are assumed to be used to update the requestor's own routing table 🔁. That's why Split Horizon must be done for them 🙌. A Request for specific networks, on the other hand, is assumed to come only from diagnostic software and not from routing 🛠️. The requester in that case wants to see the exact contents of the routing table, with nothing hidden or modified 🔎.

2.4.2. Response Messages 📨

A Response can show up for one of several reasons 🎁:

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

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

Because processing a Response can update the router's routing table, the Response must be checked carefully for validity 🧐. It must be ignored if it's not from the RIPng port 🚫. The datagram's IPv6 source address should be checked to see if it's from a valid neighbor 👀; the source must be a link-local address 🔗. It's also worth checking whether the Response is from one of the router's own addresses 🪞. Interfaces on broadcast networks may get copies of their own multicasts right away, and if a router processes its own output as new input, things get confusing fast 🌀. Those datagrams must be ignored 🙅‍♀️.

There's one more 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 make sure the hop count is 255. This absolutely guarantees the packet is from a neighbor, because any intermediate node would have decremented the hop count 💯. Queries and their responses can still cross intermediate nodes, so they don't need the hop count test 🙈.

Once the whole datagram has been validated, process the RTEs in the Response one by one 📋. Again, start with validation 🧼. Incorrect metrics and other format errors usually mean a misbehaving neighbor, and they 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 move on to the next one 🏃‍♀️. Logging the error is probably a good idea too 📝.

Once an entry passes validation, update its metric by adding the cost of the network the message arrived on. If the result is greater than infinity, use infinity instead ♾️✨. In formula form:

metric = MIN (metric + cost, infinity)

Next, check whether there's already an explicit route for the destination prefix 🔎. If there isn't one, add this route to the routing table, unless the metric is infinity (there's no point adding a route that's unusable 🙃). Adding a route to the routing table involves:

  • Setting the destination prefix and length to the ones in the RTE 📍.
  • Setting the metric to the newly calculated metric (as described above) 🔢.
  • Setting the next hop address to the address of the router the datagram came from, or to the next hop address specified by a next hop RTE 🦋.
  • Initializing 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) ⏱️.
  • Setting the route change flag 🚩.
  • Signalling the output process to trigger an update (see section 2.5) 📣.

If there is an existing route, compare its next hop address to the address of the router the datagram came from 🧩. If the datagram is from the same router as the existing route, reinitialize the timeout 🔄. Then compare the metrics. If the datagram is from the same router as the existing route and the new metric is different from the old one, or if the new metric is lower than the old one, do the following 💫:

  • Adopt the route from the datagram. That means putting the new metric in and adjusting 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, reinitialize 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 only starts when the metric is first set to infinity. If the metric was already infinity, a new deletion process doesn't start 🙅‍♀️.

If the new metric is the same as the old one, it's simplest to do nothing further (beyond reinitializing the timeout, as specified above) 😌. There is a heuristic that could be applied, though 🧠. Normally, it's senseless to replace a route when the new route has the same metric as the existing one, because the route would bounce back and forth and generate an intolerable number of triggered updates 🙃. But if the existing route is showing signs of timing out, it may be better to switch to an equally-good alternative immediately instead of waiting for the timeout to happen ⚡. So if the new metric is the same as the old one, examine the timeout for the existing route. If it's at least halfway to the expiration point, switch to the new route 🔀. This heuristic is optional, but highly recommended 🌈.

Any entry that fails these tests gets ignored, since it's no better than the current route 🫡.

2.5. Output Processing 🎀

okay so this section is all about how a router builds Response messages that carry some or all of its routing table 💅 There are three ways this processing can kick off:

  • By input processing, when a Request comes in. The Response only goes to one destination, the unicast address of whoever asked 🎯
  • By the regular routing update. Every 30 seconds, a Response with the whole routing table goes out to every neighboring router 🕰️
  • By triggered updates. Whenever the metric for a route changes, an update gets triggered ⚡

Special handling for a Request is covered back in section 2.4.1 🫶

When a Response goes to all neighbors (a regular or triggered update), it gets multicast to FF02::9, the all-rip-routers multicast group, on every connected network that supports broadcasting or is a point-to-point link. RIPng treats point-to-point links just like multicast links, since multicasting can be trivially provided on them ✨ So each directly-connected network gets one Response, sent to the all-rip-routers group, and in most cases that reaches all the neighboring routers 🌸

BUT there are cases where that's not quite enough 🙈 Maybe the network isn't a broadcast network (the ARPANET is the example given), or there are dumb routers involved. In those situations, you might need to specify an actual list of neighboring routers and send a datagram to each one explicitly. It's up to the implementor to decide whether that's needed and how the list gets specified 💜

2.5.1. Triggered Updates ⚡

Triggered updates need special handling for two reasons, and they're both very important 😭

First, experience shows triggered updates can cause excessive load on networks with limited capacity or networks with lots of routers on them. So the protocol requires that implementors include provisions to limit how often triggered updates happen. 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 happen before the timer expires, a single update is triggered when the timer expires. Then the timer gets reset to another random value between 1 and 5 seconds ⏱️ Triggered updates may also be suppressed if a regular update is due by the time the triggered update would be sent 🌈

Second, triggered updates don't have to include the entire routing table. In principle, only the routes that changed need to be included. So 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 if the implementor wants, but 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 happens 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 would appear unchanged on that network (for example, it shows up with an infinite metric), the route need not be sent. If no routes need to be sent on that network, the update may be omitted. Once all 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 that triggered updates can leave out routes that haven't 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 that latter case, the source address must be a globally valid address. In the former case, it's really important to use a link-local address, because the source address gets put into routing tables (as the next hop) in the routers that 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 that means several logical IPv6 networks are being carried over one physical medium 🌐 It's possible for a router to have multiple link-local addresses on a single interface. In that case, the router must only originate a single Response message, with a source address of the designated link-local address for that interface. The choice of which link-local address to use should only change when the current choice is no longer valid. This matters 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, and that leads 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. Remember that the maximum datagram size is limited by the network's MTU. When there's 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 to 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 go 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 an algorithm for avoiding problems caused by including routes in updates sent to the gateway they were learned from. The basic split horizon algorithm omits routes learned from one neighbor in updates sent to that neighbor. On 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 those routes in updates, but sets their metrics to infinity. Basically, it's advertising that those routes are not reachable 🚫✨ This is the preferred method of operation. However, implementations should provide a per-interface control that lets you select no horizoning, split horizoning, or poisoned reverse 🎛️

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

3. Control Functions 🎛️

This section describes administrative controls. They aren't part of the protocol per se, but experience with existing networks suggests they're important 👑 Because they aren't a necessary part of the protocol, they're considered optional. However, it is strongly recommend that at least some of them be included in every implementation. These controls are mainly meant to let RIPng connect to networks whose routing may be unstable or subject to errors. Here are some examples:

  • It's sometimes desirable to restrict the routers that updates will be accepted from, or sent to. This is usually done for administrative, routing policy reasons 🗂️
  • A number of sites limit the set of networks they allow in Response messages. Say organization A has a connection to organization B that they use for direct communication. For security or performance reasons, A may not want to give other organizations access to that connection. In that case, A should not include B's networks in updates that A sends to third parties 🙅‍♀️

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

  • A neighbor list that lets the network administrator 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 that lets the network administrator 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 🔍

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. This is SO important, bestie, because routing exchanges are exactly the kind of thing an attacker would love to mess with 😭🔥

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 Communications, 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 Integration 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.

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

Okay bestie, this is the final bit of the doc and it's literally just the contact info for the two authors 🎀✨

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

And that's a wrap on RFC 2080!! 🦋 RIPng is giving main character energy and these two literally built it, periodt 💅👑

📦 where this page comes from