Is the source IPv4 address lost when a person uses "loose source and record route" and the destination address is put before the end of the list of addresses through which routing should occur?

It wasn't quite clear to me from RFC791 whether the first value on the list should be the source address, or whether the first value on the list should be the first hop.


Since the routing is "loose", could it not hypothetically allow an attacker to include neither their own address, nor the address of the router to which they're connected, in the packet?

And... by extension...

Couldn't it allow someone to spoof the IP of a trusted host, thereby bypassing a firewall, and/or allow Internet-connected boxes to act as unwitting parts of a DoS/DDoS attack (by sending packets with the source address of the host to be attacked, to an address the attacker is aware they will reach, for a service which the attacker knows will send a response)?

If not, how is this kind of thing prevented?

(I am completely open to the possibility that these are all stupid questions; I know I am a n00b.)

  • 3
    I am also aware that this protocol has been out for a long time, and the likelihood that I've found a flaw in it exponentially approaches zero as a function of time. So, before someone tells me 'no, surprisingly, you haven't just found a way to break the internet', well, I know. I'm asking because I'm pretty sure I have the wrong end of the stick, and I like not continuing to be wrong. :P
    – root
    Mar 28, 2013 at 2:44

2 Answers 2


To complete the message from @mr.spuratic: the text from RFC 791 is:

  Loose Source and Record Route

    |10000011| length | pointer|     route data    |

    The loose source and record route (LSRR) option provides a means
    for the source of an internet datagram to supply routing
    information to be used by the gateways in forwarding the
    datagram to the destination, and to record the route

    The option begins with the option type code.  The second octet
    is the option length which includes the option type code and the
    length octet, the pointer octet, and length-3 octets of route
    data.  The third octet is the pointer into the route data
    indicating the octet which begins the next source address to be
    processed.  The pointer is relative to this option, and the
    smallest legal value for the pointer is 4.

    A route data is composed of a series of internet addresses.
    Each internet address is 32 bits or 4 octets.  If the pointer is
    greater than the length, the source route is empty (and the
    recorded route full) and the routing is to be based on the
    destination address field.

    If the address in destination address field has been reached and
    the pointer is not greater than the length, the next address in
    the source route replaces the address in the destination address
    field, and the recorded route address replaces the source
    address just used, and pointer is increased by four.

    The recorded route address is the internet module's own internet
    address as known in the environment into which this datagram is
    being forwarded.

    This procedure of replacing the source route with the recorded
    route (though it is in the reverse of the order it must be in to
    be used as a source route) means the option (and the IP header
    as a whole) remains a constant length as the datagram progresses
    through the internet.

    This option is a loose source route because the gateway or host
    IP is allowed to use any route of any number of other
    intermediate gateways to reach the next address in the route.

    Must be copied on fragmentation.  Appears at most once in a

Possible confusion arises from the reuse of the the expression "source address". An IP packet has a source address field and a destination address field, which are NOT part of this option. The contents of the option (route data in the diagram above) consist in a sequence of IPv4 addresses, and the pointer field is an index within that list.

When the packet is first emitted, the sender wishes (by this option) to direct the packet to go through a sequence of designated routers. Let's call i1, i2... in the IP addresses of these routers; let d is the final destination for the packet, and s is the sender's own address. The packet will be allowed to traverse intermediate machines not in the list (that's the difference between "loose source and record route" and "strict source and record route").

A router is, by nature, "between" two (or more) local networks, and has one IP address on each. So the address ik for router k is one of the addresses of the router; the packet sender is expecting the packet to enter that router through the local network which contains ik.

Initially, the source address field is set to s; the destination address field is set to i1; and the loose source and record option contents are set to i1, i2,... in, d. The pointer field points to i1.

When the packet reaches router 1, the router notices that the destination field address matches one of its own IP. It then does the following: it replaces the destination field address with the next IP in the list (i2) then records its own address in the list: where there was i1, router 1 puts o1. What is o1 ? It is the output address which router 1 will use, that is the address on the other local network on which the packet will next be emitted. It is an address of router 1, just like i1, but on its "other face". The pointer field is also incremented, so that it now points to the slot containing i2.

The process continues until the last address is reached. Namely, when router n was reached, it wrote d in the destination address field, and wrote on over the value in in the option. When the final destination host is reached, the option contains o1, o2,... on, d. But the source address field (which is not in the option) has remained untouched throughout the whole process; it still contains s, the initial source address.

The idea of source recording is that the destination host could respond to the source host by sending a packet with its own "loose source and record route", and may use the recorded addresses so that the packet follows the same path, in reverse order; the answer packet would initially contain:

  • source address field: d
  • destination address field: on
  • loose source and record route contents: on, on-1,... o1, s

The "output address" of each router is now the "input address", since the answer walks the path in reverse order. And the routers will then put back the ik addresses on the way back. And so on.

What's the point of this option ? Conceptually, it replaces Network Address Translation; or, more accurately, it implements NAT with the "address translation" using some state information which is in the route option itself.

Imagine that the initial sender A has address (a private address in a local network) and wishes to contact external host B with address The sender knows an "exit gateway" G which has a private IP ( but also an external IP which is "on the Internet" (say, Thus, the sender uses the loose source and record route option to indicate that the packet should do through The destination host then receives a packet which comes from (an IP address which makes no sense to the destination host), but which recorded that it went through (that's the address that the "exit gateway" recorded in the option when the packet went through it).

The B host can then respond to A by using the same option, indicating passage through (the external facing address of G). The final destination address for this answer is which has no meaning for B (it is a private address in another network), but the packet will first go to G, and G knows everything about

That way, millions of machines in a private network could "share" the external address of G, and all be able to contact external servers. One may even do connections between two hosts who are on distinct, private networks, by using source routing through two gateways.

When doing NAT, there must be some state somewhere, which remembers the translation to perform. In NAT as it is commonly used, this state is tables in the router G. G will play with the ports (an UDP/TCP concept) to keep a reference, but the actual state, i.e. the addresses which must be used and replace the ones written in the packets, are in G's RAM. The loose source and record route option allows for putting that state in the packets themselves, thus allowing G to handle millions of combinations without using any RAM at all (and when IPv4 was designed, RAM was very expensive; in 1981, when RFC 791 was written, 64 kB was huge).

However, putting state in packets means that the state could be altered externally. In 1981 everybody on the Internet was cooperating. In 2013, there are bad people. Evil people. Attackers. These people may use the source and record route option to make packets go through unexpected routes and artfully dodge firewalls. It is possible to implement and configure firewalls to inspect and block packets which use the source and record routes, but it requires more thinking. Sysadmins don't like that. They prefer usual NAT where all the state is on their machines, because it makes the problem simpler. So source routing has been deprecated in the 1990s. IPv6 designers tried to revive it, but it is encountering the same lack of support from firewall vendors and sysadmins, who prefer to kill it right away.

  • 1
    +1 for mentioning using loose source routing for stateless "NAT"
    – curiousguy
    Apr 1, 2013 at 1:33
  • +1 very detailed answer, that was a nice read Jul 9, 2017 at 11:03

Just in case there's a misunderstanding, it's not "lose", it's "loose", as in specified in a relaxed way. The IP header source address is unchanged by this (the destination address may be changed on the way though). I think it helps to selectively read "source-specified address" instead of just "source address" in this context.

I've read the RFC section again and it's not abundantly clear whether or not to place the sending system's address in the option's first field, it's neither forbidden nor required. If it is done, then the pointer must point to the subsequent (next hop) entry, so it would not be changed. If your host is a gateway (multi-homed) you might argue that it should be present.

This covers the case I think your implying where the route is over specified, and the packet reaches the destination before the routes are used up. A receiving host should not process the source-route option; though if it is a gateway the packet will be forwarded, hopefully to return when the specified routes are all processed.

The first value in the option is the first gateway/router to use in preference to that selected by normal routing, it will be replaced with the egress address of the gateway when it gets to that gateway, the destination address in the IP header is replaced with that gateway address (so that any intermediate gateways don't disrupt the path). Each matched gateway (where the option is supported) repeats the process for the next entry, up to the number of entries (and then route normally if required). Loose source routing need not be complete or contiguous.

It's trivial to forge a source IP, this usually isn't very useful, but these options may help you make that a little more useful.

The intent of loose (or strict) source routing is that the routing can be specified by the sender by way of an IP option (in the IP header, option numbers 3 and 9; and also see option number 7, for simple "record route"). The "route record" feature happens as a side effect of requesting a route, each router replaces the requested hop with its own (ingressegress) address. The "state" is also part of the header (i.e. not by inspecting TTL), there's a pointer to the next route entry that is also updated by each router as it processes the option.

As you suspect, permitting these options to cross your network perimeter is a rather bad idea: sender-specified routing opens up opportunities for probing networks, bypassing policy routing and other possibly hostile activities. While it may be rather useful for network management and diagnostics it's not really used for anything current. It briefly had a use in a type of Mobile IP, but more conventional tunnelling/encapsulation is used for this now. It was carried over to IPv6, but that specific option is deprecated due to rather poor design (specifically its applicability to DOS attacks).

Mitigations are: strip the option on your routers/firewalls or drop packets with such options, and of course strict ingress/egress filtering and/or RPF/anti-spoofing. See also RFC 6274, especially §3.13.2.

See this link if you want to experiment: http://www.synacklabs.net/OOB/LSR.html

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .