RFC 1476
RAP: Internet Route Access Protocol
RFC 1476: RAP: Internet Route Access Protocol 🦋 (part 1 of 4)
okay bestie, RFC 1476 is giving early-90s internet energy 💅 It came out of the Network Working Group in June 1993, written by R. Ullmann at Process Software Corporation. It's an Experimental protocol, and the header doesn't list anything it obsoletes or updates ✨
Status of This Memo
the official status tea: this memo defines an Experimental Protocol for the Internet community 🧪 It does not specify an Internet standard. They're actively asking for discussion and suggestions for improvement, so speak up 🗣️ For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards" 📚 Distribution of this memo is unlimited 🌈
Abstract
so the abstract is basically: this RFC describes an open distance vector routing protocol for use at all levels of the internet, from isolated LANs to the major routers of an international commercial network provider 👑 main character range, honestly.
Table of Contents 🗂️
here's the whole lineup, bestie:
1. Introduction . . . . . . . . . . . . . . . . . . . 2
1.1 Link-State and Distance-Vector . . . . . . . . . . 3
1.2 Terminology . . . . . . . . . . . . . . . . . . . 3
1.3 Philosophy . . . . . . . . . . . . . . . . . . . . 3
2. RAP Protocol . . . . . . . . . . . . . . . . . . . 4
2.1 Command Header Format . . . . . . . . . . . . . . 4
2.1.1 Length field . . . . . . . . . . . . . . . . . . . 4
2.1.2 RAP version . . . . . . . . . . . . . . . . . . . 5
2.2 RAP Commands . . . . . . . . . . . . . . . . . . . 5
2.2.1 No operation . . . . . . . . . . . . . . . . . . . 5
2.2.2 Poll . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Error . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Add Route . . . . . . . . . . . . . . . . . . . . 8
2.2.5 Purge Route . . . . . . . . . . . . . . . . . . . 9
3. Attributes of Routes . . . . . . . . . . . . . . . 9
3.1 Metric and Option Format . . . . . . . . . . . . .10
3.1.1 Option Class . . . . . . . . . . . . . . . . . . 10
3.1.2 Type . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 Format . . . . . . . . . . . . . . . . . . . . . 11
3.2 Metrics and Options . . . . . . . . . . . . . . 11
3.2.1 Distance . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Delay . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 MTU . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4 Bandwidth . . . . . . . . . . . . . . . . . . . 12
3.2.5 Origin . . . . . . . . . . . . . . . . . . . . . 12
3.2.6 Target . . . . . . . . . . . . . . . . . . . . . 13
3.2.7 Packet Cost . . . . . . . . . . . . . . . . . . 13
3.2.8 Time Cost . . . . . . . . . . . . . . . . . . . 13
3.2.9 Source Restriction . . . . . . . . . . . . . . . 14
3.2.10 Destination Restriction . . . . . . . . . . . . 14
3.2.11 Trace . . . . . . . . . . . . . . . . . . . . . 14
3.2.12 AUP . . . . . . . . . . . . . . . . . . . . . . 15
3.2.13 Public . . . . . . . . . . . . . . . . . . . . . 15
4. Procedure . . . . . . . . . . . . . . . . . . . 15
4.1 Receiver filtering . . . . . . . . . . . . . . . 16
4.2 Update of metrics and options . . . . . . . . . 16
4.3 Aggregation . . . . . . . . . . . . . . . . . . 17
4.4 Active route selection . . . . . . . . . . . . . 17
4.5 Transmitter filtering . . . . . . . . . . . . . 17
4.6 Last resort loop prevention . . . . . . . . . . 18
5. Conclusion . . . . . . . . . . . . . . . . . . . 18
6. Appendix: Real Number Representation . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . 20
9. Author's Address . . . . . . . . . . . . . . . . 201. Introduction ✨
okay so RAP is a general protocol for passing routing info around at all levels of the Internet, from private LANs all the way up to the widest-flung international carrier networks 🌍 It doesn't split things into "interior" and "exterior" routing (unless a specific policy says so), which means it isn't as restricted or complex as protocols with strict level and area definitions in their models. no cap, that's refreshing 💖
The protocol is all about spreading topology info as widely as possible, and it only aggregates it when limits of thrust, bandwidth, or administrative policy make it necessary 🦋 So RAP lets you go aggressive with resources to optimize routes wherever you want, without the restrictions that come with the simplifications of other models 🔥
While RAP uses IPv7 [RFC1475] addressing internally, it runs over both IPv4 and IPv7 networks and shares routing info between them. An IPv4 router will only be able to activate and propagate routes that are defined within the local Administrative Domain (AD), loading the version 4 subset of the address into the local IP forwarding database 🎀
1.1. Link-State and Distance-Vector
so there are two big classes of routing algorithm, link-state and distance vector 🧚 Only distance vector seems to scale from the local network (where RIP is existence-proof of its validity) up to large-scale inter-domain policy routing, where the number of links and policies is more than any one router can map out for the entire network 💅
In between, we've got OSPF, an open link-state protocol (specifically using shortest-path-first analysis of the graph, hence the acronym) with extensive development in intra-area routing 🌸
Since distance vector has proven useful at both ends of the range, it makes sense to apply it across the entire range of scales. You get a protocol that works automatically on small groups of LANs but can also apply fairly arbitrary policy in the largest networks 👑
This helps model the real world, where networks aren't neatly divided into hierarchical domains with identifiable "border" routers. They have lots of links that cut across organizational structure and go over back fences 🫶
1.2. Terminology
the RAP protocol propagates routes in the opposite direction to the travel of datagrams using those routes 🔄 To avoid confusion while explaining the routing protocol, a few terms get distinguished:
- source: where datagrams come from, the source of the datagrams
- destination: where datagrams go to, the destination of the datagrams
- origin: where routing information originates, the router initially inserting route information into the RAP domain
- target: where routing information goes, the target uses the information to send datagrams
1.3. Philosophy
the one line on philosophy that's giving me chills: Protocols should become simpler as they evolve. 🌈✨
2. RAP Protocol
okay now the actual protocol 🎀 RAP operates on TCP port 38, with peers opening a symmetric TCP connection between the RAP ports on each system. Thus only one RAP connection exists between any pair of peers 🧸
RAP is also used on UDP port 38 as a peer discovery method. Hosts (i.e., non-routing systems) may listen to RAP datagrams on this port to discover local gateways. This is in addition to, or in lieu of, an Internet Standard gateway discovery protocol, which does not exist at this writing 🔍
Next, the peers use RAP commands to send each other all the routes available through the sending peer. This happens as a full-duplex (i.e., simultaneous) exchange of information, with no acknowledgement of individual commands 🤝
Once the initial exchange is done, the peers only send updates to routes, new routes, and purge commands to delete routes that were previously offered 💜
When the connection breaks, each system purges all routes that had been offered by the peer. gone, just like that 🫥
2.1. Command Header Format
every RAP command starts with a header 🎀 The header has a length field (so the receiver can find the start of the next packet in the TCP stream), a version number, and the code for the command. On UDP, the length field doesn't show up at all: each UDP datagram must contain exactly one RAP command and must not contain data or padding after the end of the command 📦
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version | command code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+2.1.1. Length field
the length is a 32 bit unsigned number. It's the offset in bytes from the first byte of the length field of this command packet to the start of the length field of the next one. The minimum value is 8. There's no specific limit to the length of a command packet, but implementations MUST be able to at least count and skip over a packet that's too large, and then MAY send an error indication 🙈
Each version of the protocol will profile what size should be considered the limit for senders, and what (larger) size should be considered by receivers to mean that the connection is insane: either unsynchronized or worse 💀
For version 1 of the protocol, senders MUST NOT send command packets greater than 16384 bytes. Receivers SHOULD consider packets that appear to be greater than 162144 bytes in length to be an indication of an unrecoverable error 🚨
Note that these limits probably won't be approached in normal operation of version 1 of the protocol. Receivers may reasonably decline to use routes described by 16K bytes of metrics and policy. But even the most memory-restricted implementation MUST be able to skip such a command packet. it's giving "don't crash, just skip it" energy 🫶
2.1.2. RAP version
the version field is a 16 bit unsigned number. It identifies the version of RAP used for that command. Commands with different versions can be mixed on the same connection, although the usual procedure is to do the serious protocol stuff (exchanging route updates) only at the highest version common to both ends of the connection 🧠
Each side starts the connection by sending a poll command, using the highest version it supports, and then keeps going by using the highest version received in any command from the remote. The response to the poll will either be a no-operation packet at that version or an error packet at the highest version supported by the remote 🎀
This document describes version 1 of the RAP protocol. 🌸
2.2. RAP Commands
there are five simple RAP commands, described in the following sections 💅
2.2.1. No operation
the no operation command does two jobs: it resets the poll timer (see next section) of the receiver, or (as a side effect) tells the receiver that a particular version is supported. It never contains option-specific data, and its length is always 8 ✨
The no operation command is also used in a UDP broadcast to tell other systems that the sender is actively running RAP on the network and is both a possible gateway and a candidate peer 📡 If this command is being sent in response to a broadcast poll, it should be sent only to the poller 🙈
A RAP process may send these broadcasts in a startup sequence, or it may persist indefinitely to tell other systems coming online. If it persists, it must not send them more than once every 10 minutes (after the initial startup sequence). If the RAP process sends polls as part of its startup, it must not keep sending them after the startup sequence is over 🕰️
The command code for no-operation is always 0, regardless of RAP version. 🍓
2.2.2. Poll 🎀
okay so a poll is basically the "hey, u still alive?? 👀" packet 💌 A poll command packet asks the other side to send back either a no-operation packet, or some other packet if it can be sent without delay, no waiting around. (i.e., receivers MUST NOT delay a response to a poll by waiting for some other packet expected to be queued soon.) 🙅♀️ bestie, that's so iconic.
The poll command code is always 1, regardless of version, and the length is always 8. ✨
Each RAP implementation runs a timer for each connection ⏰, so that if the other system becomes unreachable, the connection gets closed or reset 💔. The timers at each end are totally independent. Each system is responsible for sending polls in time to reset its own timer. main character energy, you handle your own timer 💅
The timer MUST be reset (restarted) on the receipt of any RAP packet, regardless of whether the version or command code is known. 🔄 so any RAP packet at all resets it, no matter what version or command code it has.
In normal operation, if route updates are being sent in both directions, polls may not be necessary for long periods of time, since the timers keep getting reset 🙌. When the connection is quiet, both timers will typically get reset because the side with the shorter timer does a poll and gets a no-operation back 🌸. RAP implementations MUST NOT be dependent in any way on the size or existence of the remote timer. 🚫 don't rely on the other side's timer at all, periodt.
An implementation that has access to information from the TCP layer, such as the results of TCP layer keepalives, MAY use this instead of or in addition to a timer. 🧚 However, the use of TCP keepalives is discouraged. This procedure doesn't ensure that the remote RAP process is alive, only that its TCP is accepting data. So there's a failure mode here that wouldn't exist for active RAP layer polls. 💀
The timer MUST be implemented, SHOULD be configurable in at least the range 1 to 10 minutes on a per-peer basis, and MAY be infinite (disabled) by explicit configuration. ⏳
On UDP, a system (router or non-routing host) may send RAP polls to try to locate candidate peers or possible gateways 🔍. Such a system must not keep sending polls after its startup sequence, except that a system which actually has offered traffic for non-local destinations, and has no available gateways, may keep sending periodic polls to try to acquire a gateway 🫶.
2.2.3. Error 🚨
The error packet is how you report an error, whether it's fatal, serious, or just informational 📣. It carries a null terminated text description in ISO-10646-UTF-1 of the condition, which can be useful to a human admin, and SHOULD be written to a log file. (The machine isn't expected to understand the text, lol 🤖)
Errors are actual failures (from the receiver's point of view) to use the correct syntax and semantics of the RAP protocol itself, or "failure" of the receiver to implement a version of the protocol. 😬 Other conditions that may need action from the peer (like purging a route) get their own command codes. 🏷️
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version (1) | command code (2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| error code (0) [reserved] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| description |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The RAP system receiving an Error packet MUST NOT regard it as fatal, and close the connection or discard routes. 🙅 If the sending system wants the condition to be fatal (unrecoverable), its proper move is to close the connection. This requirement exists to prevent the kind of failure mode seen with hosts that killed off TCP connections on receipt of ICMP Host-Unreachable notifications, even when the condition was transient. 😭 We do not want to discourage error reporting, the way some implementations avoided sending ICMP datagrams to deal with overly sensitive hosts. 📢
An error packet MUST NOT be sent in response to something that is (or might be) an error packet itself. 🔁 Subsequent versions of RAP should keep the command code point (2) of the error packet. 🔒
2.2.4. Add Route 🦋
The add route command offers a route to the receiving peer. As noted later, it MUST be a route actually loaded into the forwarding database of the offering peer at the time the add route is sent. 📬
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RAP version (1) | command code (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| distance | (MBZ) | mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| destination network |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| route identifier |
+ +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metrics and options .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The add route command describes a single offered route, along with the metrics and other options (like policies) that go with it. 🎁
Distance is a simple count of hops to the RAP process (or other routing process) that originated the route, bumped up every time the route is forwarded 🦶. Its initial value may be greater than 1, particularly for a route that is administratively configured to aggregate routes for a large network or AD. It may also enter the RAP routing domain for the first time with a non-zero distance because the route originated in RIP, OSPF, or BGP. If so, the distance carried in that protocol is copied into the RAP route. 🗺️
The mask is a count of how many prefix bits are ones in the binary representation of the network mask 🔢. Non-contiguous masks aren't supported directly. 🙃 (The destination restriction option may be used to give another, non-contiguous, mask. Then the header mask describes the number of contiguous ones instead.)
The route identifier is a 64 bit value that the IP forwarding module on the sending host can use to rapidly identify the route and the next hop for each incoming datagram ⚡. The host receiving the route places this identifier into the forward route ID field of the datagrams being sent to this host.
The route ID is also used to uniquely identify the route in the purge route operation. 🆔
2.2.5. Purge Route 🧹
The purge route command requires that the receiving peer delete a route from its database if it's in use, and requires that it revoke that route from any of its peers it has offered the route to. 🫠 This command should preferably be sent before the route is deleted from the sending peer's forwarding database, but this is not (cannot be) required. It should be sent without delay when the route is removed. ⏱️
The command code is 4. The format is the same as add route without any added metrics or options. 📋
If the route identifier in a purge route command is zero, the command requires the deletion of all routes to the destination previously offered by this peer. 💥
3. Attributes of Routes 💎
There are a rather large number of possible attributes 🌈. Possibilities include both metrics, and other options describing things like policy restrictions and alterations of proximity. Any particular route will usefully carry only a few attributes or none at all, particularly on an infrastructure backbone. A reasonable policy for the routers that make up a backbone might be to strip all attributes before propagating routes (discarding routes that carry attributes with class indications prohibiting this), and then add (for example) an AUP attribute to all routes propagated off of the backbone. A less drastic method would be to simply prefer routes with no restrictions, but still propagate a route with restrictions if no other is available. 🦄
Most options can occur more than once in a route if there is any sensible reason to do so. ✌️
3.1. Metric and Option Format 🧩
Each metric or option for a route begins with a 32 bit header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length | C | format | type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option data ... | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RAP Option/Metric Header FormatA description of each field, in case you need the lowdown 📝:
length length of the option or metric
C option class, see below
format data format
type option type identifier
data variable length3.1.1. Option Class 🎭
This field tells implementations what to do with routes containing options or metrics they don't understand 🤷♀️. No implementation is required to implement (i.e., understand) any given option or metric by the RAP specification itself, except for the distance metric in the RAP header. 💅
Classes:
0 use, propagate, and include this option unmodified
1 use, propagate, but do not include this option
2 use this route, but do not propagate it
3 discard this routeClass 0 is an imperative, bestie 🫡: if the route is propagated, the option must be included.
Class and type are entirely orthogonal, so different implementations might use different classes for the same option or metric. 🧠
3.1.2. Type 🔢
The type code identifies the specific option or metric. The codes are part of the option descriptions that follow. 🏷️
Type 0 indicates a null (no-operation) option. It should be class zero, but an implementation that "understands" the null option may decline to propagate it. 🫥
Note that since an implementation may delete an option of class 1 by simply setting its type to 0 and forwarding the route description, class 1 does not provide any confidentiality of the content of an option. 🙈 so class 1 is not a privacy move, bestie 🔓
3.1.3 Format 🧾
okay so the format field is basically telling you what kind of stuff sits after the option header 👀 here's the whole lineup:
0 none, no data present.
1 one or more 32-bit signed integers
2 a character string, null terminated
3 one or more real numbers
4 an octet string
5 one real, followed by a character stringformat is also orthogonal to type 🧠 (fancy way of saying they're totally independent!!), but a particular type is usually only reasonably represented by one format. that's the magic bit, bestie 🪄 it means you can decode every option value for logging and troubleshooting even when the type is unknown to you. (just know a brand-new unknown format will still be a problem 😭)
format 4, octet string, gets printed in dotted-decimal byte form, because it's normally an internet address 🌐
format 5 is for dimensioned parameters, where the character string tells you the dimension or scale 📏
3.2 Metrics and Options 💖
whenever possible, metrics are kept in base units of bytes and seconds, kinda like how the physics crew does MKS (meter-kilogram-second) and CGS (centimeter-gram-second) 🤓
bytes aren't the real primitive, bits are 🫶 so we're using a multiple of 8 that doesn't match the usual decimal prefix vibes. but since K (kilo) is often taken to mean 1024, and M (mega) to mean 1,048,576 (or even 1,024,000), we allow this liberty ✨
distance is measured in units that are also unique to this field. it's the integer number of times a datagram must be forwarded to reach the destination. (hop count, obviously 🦋)
3.2.1 Distance 📏
the Distance metric counts the number of hops on a route, and it's included in the RAP route command header 🎀
the initial distance at insertion into the RAP domain by the origin of the route MUST be less than or equal to 2z, where z is the number of zero bits in the route mask. this one is a real rule, not a suggestion 💅
if the origin derives the route from RIP or OSPF, and the distance exceeds 2z, the route must not be used 🚫
when a router originates a route designed to permit aggregation, the distance is usefully set to more than 0 🌸 this lets simple subset aggregation happen without propagating small distance changes over and over as the internal diameter of the described network changes. no more constant drama 🙈
for example, for routers designated to announce a default route for an AD, with a 24/48 mask, the maximum initial distance is 96 ⭐
3.2.2 Delay ⏱️
the Delay metric (Type = 2) measures the one-way path delay. it's usually the sum of the delays configured for the gateways and interfaces, but it might also include path segments that are actually measured 🧚
format is real (3), with one value. the units are seconds ⏳
3.2.3 MTU 📦
the MTU metric (Type = 3) measures the minimum value over the route of the Maximum Transmission Unit, aka the largest IP datagram that can be routed without resulting in fragmentation. the smallest link wins, periodt 👑
format is one integer, measuring the MTU in bytes.
3.2.4 Bandwidth 🚿
the Bandwidth metric (Type = 4) measures the minimum bandwidth of the path segments that make up the route. weakest link energy 💜
format is one real, representing bandwidth in bytes/second.
3.2.5 Origin 🌱
the origin attribute (type = 5) identifies the router that originally inserted the route into the RAP domain. it's one of the IP addresses of the router, and the format is 4 🫶
3.2.6 Target 🎯
the target attribute (type = 6) identifies a host or network that the route should be propagated toward, regardless of the proximity filtering that would otherwise happen. this helps set up tunnels for hosts or subnets "away from home" 🧳 it can force the route to propagate all the way to the home network, or try to propagate a better route to a host that the origin has made a connection with (like TCP) 💖
also, a router can tell these two cases apart during proximity filtering by comparing the route described with the host or network identified by the target option. so clever 🧠
format is 4.
3.2.7 Packet Cost 💸
the packet cost metric (type = 7) measures the actual cost (to someone) of sending data over the route. it's probably either class 3 or 0. format is 5 🎀
the real number is the cost in currency units/byte. tariffs set in packets or "segments" should be converted using the nominal (or actual path) size. for example, Sprintnet charges for DAF connections within its network are US$1.40/Ksegment, so for segments of 64 bytes, the cost is 0.000021875 USD 🤑
the string is the 3 capital letter ISO code [ISO4217] for the currency used. the funds codes and the codes XAU, XBA, XBB, XBC, XBD, and XXX are not used 🙅♀️
if a route already has a packet cost in a different currency attached to it, another instance of this option should be added. RAP implementations MUST NOT attempt to convert the currency units except when actually making a route selection decision. so the effects of a currency conversion should never be propagated, except for the proper effect of that selection decision. no sneaky conversions, bestie 🫢
3.2.8 Time Cost ⌛
the time cost metric (type = 8) measures the actual cost of holding one or more paths in the route open to send data. it's probably either class 3 or 0. format is 5 🎀
the real number is the cost in currency units/second. for example, Sprintnet charges for international connections (to typical destinations) are US$10/hour, so the cost is 0.002777778 USD 🌍
the other notes about codes used and conversions in the previous section also apply 🔁
3.2.9 Source Restriction 🚪
a source restriction option (type 9, format 4, class 2 or 3) indicates that a route may only be used by datagrams from a particular source or set of sources. the data consists of a network or host number, plus a mask to qualify it. if multiple source restriction options are included, the restriction is the logical union of the sources specified, so any of them are permitted 🫶
source restrictions must be added to routes when the RAP system has security filters set in the IP forwarding layer. this is necessary to stop datagrams from taking "better" routes that end with the datagram being silently discarded at the filter 😭 note that this propagates confidential information about the security configuration, but only toward the net that's authorized to use the route, if the RAP implementation is careful about where it's propagated.
heads up, bestie: that last bit is only safe if the RAP implementation is careful about where it propagates things 🚨
3.2.10 Destination Restriction 🎯
a destination restriction option (type 10, format 4, class 3) only provides a non-contiguous mask, since the destination has already been specified in the command header. the data is the destination network and mask 🧩
3.2.11 Trace 🕵️♀️
trace (type 11, format 4, class 0) gives an indication that the route has propagated through a particular system. this can be used for loop detection, plus various troubleshooting methods. the data is one internet address, one of the addresses of the system 🔍
if an arriving route already carries a trace identifying this system, and it's not an update, it gets discarded. if it is an update, the route is purged 💀
trace SHOULD NOT be simply added to every route traversing a system. it's way better to add it (if you're using it for loop detection) when there's a suspicion that a loop has formed 🙅♀️
when the distance to a destination has increased twice in a row in a fairly short period of time, and the number of trace options in the route didn't increase as a result of the last update, the RAP process should add a trace option identifying itself to the route. basically, when a loop forms, one router will pick itself to be the tracer, add itself, and break the loop after one more turn 🔄 if that fails for some reason, another router will add its trace. each router ends up depending only on its own trace to break the loop, even if the other routers are using other methods or just counting out the route. such a main character energy move 👑
3.2.12 AUP 📜
the AUP (Acceptable Use Policy) option (type 12, format 2, class any) tags a route as usable only according to a network's policy. this might be used to keep (for example) commercial traffic off the net, or to prevent accidental use of an organization's internal net 🏢 (it's not a security barrier in the sense of forwarding filters, but it does give cooperative info about whether a net is usable 🤝)
the data is a domain name, probably the name of the network, although it could be the name of another organization. e.g., the routers that are subject to the NSF AUP might add NSF.NET as the descriptor of that policy 📚
3.2.13 Public 📡
public (type 13, format 0, class 2 or 3) marks a route as consisting partly of a public broadcast medium. examples of a public medium are direct radio broadcast or a multi-drop cable where other receivers, not associated with the destination, may read the traffic. so a TV cable is public, but a LAN inside an organization isn't, even if it can be easily wiretapped 📺
this is meant for cable TV providers to identify routes that shouldn't be used for private communications, even though the bandwidth is super attractive 🥺
4. Procedure 🧭
routing information arrives in the RAP process from other peers, from (local) static route and interface configuration, and from other protocols (e.g., RIP) 📬 the RAP process filters out routes that are of no interest (too detailed or too "far away" in the topology) and builds an internal database of available routes 🗂️
from this database, it selects the routes that are going to be active and loads them into the IP forwarding database ✅
then it advertises those routes to its peers, at a greater distance 📣
-------------------------------------------------------------------
[incoming routes]
|
v
[proximity filtering/aggregation] [static routes]
| |
v v
[route database] ---> [selected active routes]
^ |
| v
[RIP, etc. routes] [output filtering]
|
v
[routes advertised]
-------------------------------------------------------------------4.1 Receiver filtering 🚰
the first step is to filter out offered routes that are too "far away" or too specific. the filter is a maximum distance at which a route is considered usable for each possible (contiguous) mask 🔎
routers that need universal connectivity must either pass all routes through the filter regardless of distance (short of "infinity") and use aggregation to reduce them, or have a default route to a router that does this 🌐
the filter may be adjusted dynamically to fit limited resources. but if the filter is opened (made less restrictive), there may be routes that were already offered and discarded that will never become available again 😩
4.2 Update of metrics and options 🔧
the process then updates any metrics present on the route to reflect the path to the RAP peer. MTU and bandwidth get minimized, while delay and cost get added in. distance is incremented 📈 any unknown options cause class-dependent processing: the option gets discarded (class 2), the route gets discarded (class 3), or the route gets marked as non-propagatable (class 1) 🙈
policy options that are known may cause the route to be discarded at this stage 🗑️
4.3. Aggregation ✨
okay so next up is aggregation 🧚 this is where a router takes routes that are subsetted by other routes through the same peer and bundles them up. but it should not be done automatically in every possible case 💅 the more info that gets propagated, the more effective forward route identifiers are likely to be, esp when you aggregate into a default route 🌸
In general, a route can be included in an aggregate, and not propagated further, if it is through the same peer (next hop) and has a smaller distance metric than the containing route. (so datagrams will always travel "downhill" as they take more specific routes 🦋)
the usual case is that routes derived from interface configurations on the routers they came from get subsumed into routes offered by routers that are explicitly configured to route for an entire network, area, or AD 👑 if the larger area becomes partitioned, unaggregatable routes will show up (because routes outside the area become the shortest distance routes) and traffic will flow around the partition 🌈
attributes of routes, esp policy options, may prevent aggregation and may result in routes simply being discarded 💀
some info about aggregation also needs to be represented in the forwarding database, if the route is made active. the router will need to make a decision as to which forward route identifier to use for each datagram arriving on the active route 🫶
4.4. Active route selection
the router picks which routes go into the IP forwarding database and get actively used to forward datagrams 🎀 it chooses from the set of routes after aggregation, combined with routes derived from other protocols such as RIP. this selection may be made on any combination of attributes and options desired by local policy ✨
4.5. Transmitter filtering
finally, the RAP process has to decide which routes to offer to its peers 💖 these must be a subset of the active routes, and may in turn be a selected subset for each peer. arbitrary local policies may be used in deciding whether or not to offer any particular route to a given peer 🦋
BUT here's the important part 🚨 the transmitter must ensure that any datagram filters are represented in the offered route, so that the peer (and its peers) will not route into a black hole. no black holes, bestie 🕳️🙅♀️
4.6. Last resort loop prevention
RAP is designed to support lots of different kinds of routing selection algorithms, and let them interact to varying extents 🧚 routes can be shared among administrations, and between systems managed with more or less sophistication.
this leaves one absolute requirement: routing loops must be self-healing, regardless of the algorithm used on each host 🔥 there are two caveats:
- a loop will not fix itself in the presence of an error that continually recurs (thus re-generating the loop) 😭
- the last resort algorithm does not provide rapid breaking of loops, only eventual breaking of them, even in the absence of any intervention by (human) intelligence 🙈
the algorithm relies on the distance in the RAP route header. this count must be updated (i.e., incremented by one) at each router forwarding the route 🍓
routers must also impose some limit on the number of hops permitted in incoming routes, and discard any routes that exceed the limit. this limit is "infinity" in the classic algorithm. in RIP, infinity is 15, which is way too low for general inter-domain routing 💀
in RAP, infinity is defined as 2z + i, where z is the number of zero bits in the mask (as described previously) and i is a small number which MUST be configurable ✨
note that RAP leans on the last resort algorithm, "counting to infinity," much less than predecessors such as RIP 💜 routes in the RAP domain will usually be purged from the net, because the purge route command is flooded without the delays typical of periodic broadcast algorithms 🦋 only in some cases will loops form, and they will be counted out as fast as the routing processes can exchange the information 🌸
5. Conclusion ✨
unlike prior routing protocols, RAP is designed to solve the entire problem 👑 from hands-off autoconfiguration of LAN networks, all the way to implementing the most complex policies of international carriers 🌈 it provides a scaleable solution to carry the Internet forward into a future where essentially all users of data transmission use IP as the fabric of their networks 🫶
6. Appendix: Real Number Representation 🎀
real numbers are represented by a one byte exponent, e, in excess-128 notation, and a fraction, f, in excess-8388608 notation, with the radix point at the right. (i.e., the "fraction" is actually an integer. 🤓)
e is thus in the range 0 to 255, representing exponents (powers of 2) in the range 2^-128 to 2^127 🧚
f is in the range 0 to 16777215, representing numbers from -8388608 to 8388607 💖
the value is (f-8338608) x 2^(e-128)
the real number is not necessarily normalized, but a normalized representation will, of course, provide more accuracy for numbers not exactly representable 🦋
example code, in C:
#include <math.h>
typedef struct {
unsigned e : 8;
unsigned f : 24;
} real;
double a; /* input value */
real r;
double b; /* output value */
double d;
int e32;
/* convert to real: */
d = frexp(a, &e32);
r.e = e32+105;
r.f = (int)(d*8388608.0) + 8388608;
/* convert back: */
b = ldexp((double)r.f - 8388608.0, (int)r.e - 128);7. References 📚
- [ISO3166] International Organization for Standardization. Codes for the Representation of Names of Countries. ISO 3166, ISO, 1988.
- [ISO4217] International Organization for Standardization. Codes for the representation of currencies and funds. ISO 4217, ISO, 1981.
- [RFC791] Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, DARPA, September 1981.
- [RFC1058] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, Rutgers University, June 1988.
- [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
- [RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, MIT, BBN, CNRI, ISI, UCDavis, December 1991.
- [RFC1338] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: an Address Assignment and Aggregation Strategy", RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.
- [RFC1475] Ullmann, R., "TP/IX: The Next Internet", RFC 1475, Process Software Corporation, June 1993.
8. Security Considerations 🚨
security issues are discussed in sections 3.2.9 and 3.2.12. please go read those sections, they matter a lot 🙏
9. Author's Address 💌
Robert Ullmann
Process Software Corporation
959 Concord Street
Framingham, MA 01701
USA
Phone: +1 508 879 6994 x226
Email: Ariel@Process.COM📦 where this page comes from
- ietf: rfc1476 1993-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms