Loose Source Record Route (LSRR) Discussion

Contents

Discussion

LSRR is an option in the IP header that allows one to specify a collection of nodes that the packet must traverse before reaching the destination. An important thing to realize is a packet cannot be loosely routed through a single homed source, it must be a multi-homed node. A single homed node does no routing.

This is exceedingly useful when used inconjunction with traceroute. For the most enlightening use set the destination to the node you are currently on, and loose route to some distant gateway. For example:

maxwell (~/cis610/traceroute) 50 # tracer maxwell unh-gw.near.net LSRR enabled, IP option data 83 0b 04 83 c0 3e 02 c6 6a c1 29 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 traceroute 198.106.193.41, 30 hops max, 8 byte packets 1 uo-cs-gw.uo.ojgse.edu (198.106.193.33) 2 ms 2 ms 2 ms 2 nwnet-gw.transit.uoregon.edu (198.107.238.100) 5 ms 3 ms 4 ms 3 198.104.198.26 9 ms 198.104.198.34 7 ms 198.104.198.26 6 ms 4 eugene2-gw.nwnet.net (198.104.199.2) 9 ms 8 ms 8 ms 5 198.104.196.34 14 ms 198.104.196.114 22 ms 17 ms 6 192.80.12.74 25 ms 192.80.12.82 24 ms 192.80.12.74 23 ms 7 seabr2-gw.nwnet.net (198.104.194.194) 24 ms 23 ms 27 ms 8 mci-cpe-fddi.nwnet.net (192.147.179.3) 28 ms 82 ms 23 ms 9 border1-hssi1-0.Seattle.mci.net (204.70.52.5) 27 ms 19 ms 84 ms 10 core-fddi-0.Seattle.mci.net (204.70.2.145) 78 ms 843 ms 39 ms 11 core-hssi-2.Chicago.mci.net (204.70.1.29) 83 ms 85 ms 83 ms 12 core-hssi-2.Boston.mci.net (204.70.1.45) 97 ms 109 ms 104 ms 13 border1-fddi0-0.Boston.mci.net (204.70.2.34) 285 ms 185 ms 209 ms 14 nearnet.Boston.mci.net (204.70.20.6) 208 ms 531 ms 237 ms 15 mit3-gw.near.net (192.233.33.10) 209 ms 171 ms 230 ms 16 prospect-gw.near.net (131.192.27.1) 223 ms 112 ms 109 ms 17 harvard-gw.near.net (131.192.32.1) 268 ms tang-gw.near.net (131.192.7.1) 252 ms harvard-gw.near.net (131.192.32.1) 151 ms 18 bu1-gw.near.net (131.192.4.2) 155 ms bu1-gw.near.net (131.192.1.2) 140 ms bu1-gw.near.net (131.192.4.2) 157 ms 19 dartmouth-gw.near.net (131.192.54.2) 159 ms 145 ms 196 ms 20 unh-gw.near.net (131.192.62.2) 129 ms 138 ms 229 ms 21 dartmouth-gw.near.net (131.192.62.1) 128 ms 114 ms 125 ms 22 bu1-gw.near.net (131.192.54.1) 120 ms 122 ms 246 ms 23 tang-gw.near.net (131.192.4.1) 200 ms 244 ms 221 ms 24 mci-its.near.net (192.233.33.11) 163 ms 154 ms 140 ms 25 border1-hssi1-0.Boston.mci.net (204.70.20.5) 360 ms 161 ms 217 ms 26 core-fddi-0.Boston.mci.net (204.70.2.33) 162 ms 177 ms 154 ms 27 core-hssi-4.Chicago.mci.net (204.70.1.46) 134 ms 146 ms 166 ms 28 core-hssi-3.Seattle.mci.net (204.70.1.30) 149 ms 333 ms 170 ms 29 border1-fddi0-0.Seattle.mci.net (204.70.2.146) 247 ms 185 ms 233 ms maxwell (~/cis610/traceroute) 51 #

So the packet scoots off to unh-gw.near.net and then comes running back! If LSRR was not used we could not see the return path. Without LSRR, to determine the return path a traceroute would have to be done on unh-gw.near.net back to maxwell which is impossible (as far as I know) since unh-gw.near.net is a gateway, not a host.

The format of the IP option data is quite simple. The first 3 bytes are reserved for IP option code, length and pointer. Since IP option data can bv used for different functionality (timestamp, strict routing, route and record), the code field specifies the type of service. The length field, oddly enough, state the size of the optional data which cannot be larger than 40 (discussed later). Finally the pointer field points to the starting IP address in the remaining data section. To pictorially:

MAX 1 40 -------------------------------- |1|2|3| I1 | I2 | I3 | I4 | ... -------------------------------- 1 = Code 2 = Length 3 = Pointer I1 = IP address 1 I2 = IP address 2 I3 = IP address 4

Now to explain why the IP addresses are in the IP options. The loosely routed gateways must be stored somewhere while the packet screams across the internet. The pointer field points to the next node that the packet should be sent to. So, the pointer field initally is 4 (it is a 1-indexed pointer) and is increased by 4 after reaching node it is currently pointing to. At the first node, the final destination address (as compared to loose routed node) must be copied in as the last address to route through. I don't know why this is the case, I would think that this information is in the ip source address field. Admittedly this field would be overwritten with the first gateway however this task could be done by a lower level. Ok, flame off.

There is an upperlimit of 40 characters for the IP data. With 3 bytes commited to the header information and 4 bytes commited for the final node, there only remains 33 bytes to contain loose node information. Well, 33 / 4 = 8 hosts with 1 byte remaining. Only 8 hosts can be loosely routed through, not counting the final node.

Now go back to the example of LSRR. The hex data that is printed out is the 40 bytes of the IP option data. The code 83 specified LSRR, the 0b is 11 in decimal, the length of packet. Finally the pointer is initially 4, the first address to route through. The next 8 bytes specify the addresses to route through. The first 4 bytes are for unh-gw.near.net and remaining bytes are for maxwell.

Conclusion

Except for rfc1108, "Security Options for the Internet Protocol", the format for all IP options start with the 3 bytes header defined above. Once the desired effect is correctly encoded into the 40 bytes and sent, the internet and properly implement hosts do all the work. It should be noted that the traceroute was implemented to solve the space limitation problem in the IP option data. The maximum room of 40 bytes (9 address including the starting node) is not enough to trace packets over the network. The traceroute program evades this bottleneck by not recording route in the IP option data.

Craig Smith

Last modified: Wed May 24 14:06:08 CEST 2000