This is the second in my series of Internet engineering and network policy documents. There are several decent explainations of the behavior as well as good presentations on the mechanics, for those that who need an extra hand digesting RFC791. But I have yet to see a clearly-stated rationale why and where every network should use some source-routing.
What is commonly referred to as using or allowing LSRR (sometimes "LSSR", "loose-source routing", or correctly "loose-source record-route"), is simply not blocking two IP options from being used: IP option 3 (loose-source) and IP option 7 (record-route). Source-based routing means that the source specifies how the data is to travel through the network. The originator of the packet is in control, rather than the routing protocols. Hopefully, one believes that one's network is run by the engineers and operators better than by your users, so normally you have routers making the actual decisions.
Strict source-based routing (SSR) requires a hop-by-hop specification of the path data should take. This overrides normal routing protocols, and requires specific knowledge of network topology to be effective. Rather than take the network's interpretation of "best path" to reach a destination, SSR data will only follow the path specified in the IP header.
Loose source-based routing (LSR) requires at least one, but not all, intervening hops to be specified. This only partially ovverides normal routing protocols, and requires the knowledge of only one point in the network's topology. The network will use its interpretation of "best path" to reach the each specified gateway, and continue to use normal routing protocols to send the data to the destination.
The distinction is the same as making a trip with a specific set of driving directions (SSR) and making a trip driving by visiting landmarks without a care of the intervening roadways. [diagram for SSR vs LSR goes here]
You can send all the data you like in any directions when someone is supporting either flavour of source-routing. If you're using it as a test or probe into a network, you need some form of confirmation that your data successfully made it through. Conveniently, the intermediate gateways that are specified in both loose and strict source routing are required to record that they were visited.
This is actually a beneficial side-effect of the requirement that the IP header needs to have the same length when it arrives at the destination as when it was created. An inconsisant length means a bad packet, and it would just be thrown away. Each time a gateway is reached, it removes its own IP address from the list of gateways-to-visit, and places it into the list of visited hops. This is the route record, and your data's receivers can decode this for use in your application.
Any network that has settlement-free peering interfaces with other networks should have LSR enabled on the routers where those interfaces live. This allows peer to examine routing policy in a concrete, verifiable way. The subjective manner of testing by contacting the other operator is both subject to error and consumes unnescessary, expensive human resources. It allows you to detect peers that are misconfigured, abusing your network, or having their networks abused.
SSR is not very useful when poking your fingers into someone else's network, which is presumable opaque to you, since it requires specific topology knowledge. Additionally, SSR is limited to a small number of hops due to the IP packet size; since you have to list all the hops the packet will visit in the header, there's only room for 8 intervening networks
The irony is that with source-routing allowed across your entire network, you can be abused. But just running it at the edges allows your peers to verify that you're not abusing them, and it is just a token of good faith to allow them to check you if you want to check them. So to avoid bad faith, you use a part of something that can be abused to avoid being abused.
Some of it stems from the old days (for some value of old) of many players of various sizes at only a few broadcast-based exchange points. Some networks could dump traffic (even just temporarily) onto other networks without their knowledge. Requiring a peer to have LSRR enabled allowed verification of this behavior when it was suspected, without having to involve the other network's operators, the exchange operators or others. Such actions are indeed less prevalant in the current Internet, as there are many better tools to monitor traffic, exchanges have become serious businesses where customer practices are scrutinized, and most serious networks have private interconnects in addition to any public ones. But there still are unscrupulous operators, companies, and customers.
Likewise, routing policies are more complicated today. Thanks in no small part to selective regionalized peering, settlement-based partial transit, MPLS and other policy-routing techniques, content redirection and the like, what is "normal operation" on one network may be completely insane on another. It is useful to be able to check what the other network is actually doing with your data. LSRR allows you to get a peek at that, almost as good as the peer network having a public-access router (or web interface). This lets you at least see what paths your peer will actually use, not just email from them stating the routes they have seen.
There are many networks that explicitly require LSRR for peering. Here's a list, current as of date at the bottom of this document. If you have any additional, corrections, etc then please do send them.
There's two important categories of things to check: traffic you're supposed to get and traffic you're NOT supposed to get. The latter is obviously a large set, so you want to check some boundary conditions. The test should be sourced from your peering router, or if from an internal host be prepared to LSRR via two gateways: your peering router and the peer's router.
[simple exmaples of traceroute tests here]
From here, you could zip over to my main gweep pages.
Cheers,
joe
Last updated Fri Dec 6 17:22:39 EST 2002