jonab@CAM.UNISYS.COM (Jonathan P. Biggar) (09/10/87)
I am implementing IP in Ada and have several questions about IP options
that are not clearly answered in either RFC 791 or MIL-SPEC 1777:
1) Are the record route and timestamp options modified by the source and
destination systems, or are they only modified by gateways?
2) When using either loose or strict source routing, does the next hop
or the final destination go in the destination address field of the
IP header? For example, if I want to route from host A through B and
C to D, is the destination address B with source route C and D, or
is the destination address D with source route B and C?
3) Is it legal to have both loose and strict source routing options in the
same IP packet? If so, how do you handle this case?
Jon Biggar
jonab@cam.unisys.combrescia@PARK-STREET.BBN.COM (Mike Brescia) (09/10/87)
... not clearly answered in either RFC 791 or MIL-SPEC 1777:
1) Are the record route and timestamp options modified by the source and
destination systems, or are they only modified by gateways?
A clear recommendation that hosts implement them would help. You could make
use of the information provided by the source host such as 'which interface
was used to actually send the packet', and the destination host 'what time was
the packet received'.
2) When using either loose or strict source routing, does the next hop
or the final destination go in the destination address field of the
IP header?
Next hop. A rationale for this choice, based on processing power needed, is
that a gateway does not have to look at the options unless the IP destination
address is the gateway. Then you look for options, and, finding a source
route, send it back out again.
3) Is it legal to have both loose and strict source routing options in the
same IP packet? If so, how do you handle this case?
Legal? Since it's not forbidden, I guess so. What path would a host program
expect such a packet to trace? How more useful is it than just one option?
Think what the gateway must do if both are present; process the first? do the
second if the first is counted out? do the first and ignore the second?BILLW@MATHOM.CISCO.COM (William Westfield) (09/18/87)
[ Indented quotes from Jonathan Biggar, ">"ed quotes from Mike Brescia ]
2) When using either loose or strict source routing, does the next hop
or the final destination go in the destination address field of the
IP header?
>Next hop. A rationale for this choice, based on processing power needed, is
>that a gateway does not have to look at the options unless the IP destination
>address is the gateway. Then you look for options, and, finding a source
>route, send it back out again.
Unfortunately this rationale is completely false, since there are many
IP options that must be processed whether or not the IP destination is
the gateway's address. (These include record route, timestamping, and
security.)
A better reason is the behavior that you get when some gateway does
not implement source routing is much more sociable this way.
Consider a packet sent from A to D with source route B:C:D, and where
B does not implement source routing. If the original destination D
stays in the header through the entire trip, then the packet will
arrive at B, and be forwarded on to some gateway (perhaps C) without
processing the source route option. C will get the packet, notice
that it has an incomplete source route, and forward it to the next
gateway in the list, which is still B. The packet will loop between
B and C until it dies. Depending on the type of link between them,
this could be very expensive in some sense.
When the IP destination is replaced at each hop, all that happens is
that B receives the packet, and probably throws it out due to some
higher level protocol checksum faliure...
Bill Westfield
cisco Systems
-------brescia@PARK-STREET.BBN.COM.UUCP (09/18/87)
Bill,
When I talked about processing IP options only if the packet was addressed to
the gateway, that was historically accurate for the LSI11 core gateways, which
did not implement record route, timestamping or security options.
Because of the extra overhead of doing a complete scan of the IP options at
every gateway hop, I propose, only slightly tongue-in-cheek, that we extend
the IP header by 8 (16? 32?) bits for a flag word indicating that certain
options are present and should be scanned. Use bit[i] to indicate the
presence of an option whose value is "i". Gateways which do not handle
security, for example, can rapidly dispose of (oops, forward :-) those packets
with only the security option bit on.
This is an extension of an earlier idea (source unknown) which used a single
bit in the IP header to declare the presence of options which needed
processing at every gateway.
Note: if you have any flames about the specifics of the proposal, I doubt that
I will answer them. I did want to get in a bid for faster handling of
packets. Maybe I am still too concerned with 'efficiency'.
Mikekarn@FALINE.BELLCORE.COM (Phil R. Karn) (09/18/87)
Just how many datagrams in the Internet even carry options anyway? I recently discovered that the implementation of source routing I did over a year ago was buggy. Not because it didn't work in operation, but because I re-read the spec the other night and realized I had done it wrong. I've never even seen a datagram with options. It might seem that it's not really worth worrying much about performance when processing IP options if they are that rare. Phil