markl@jhereg.lcs.mit.edu (10/07/86)
> > host A gate B gate C host D > +------+ +------+ +------+ +------+ > | | | | | | | | > | A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 | > | | net 1 | | net 2 | | net 3 | | > +------+ +------+ +------+ +------+ > >where A1, B1, B2, etc. are IP addresses. I think that the upper layer >protocol in host A should pass the following IP header values to the >IP layer: > source:A1 destination:B1 route:B1,C2,D3 offset:4 I know how you feel about the source routing spec [I had to implement it for our NETBLT IP protocol -- a bit of a headache...]. Indeed, the offset at start is 4, however the route is not quite as you specify it. The source host is A1 and the destination host B1; the initial route is C2,D3. on host A: source:A1 destination:B1 route:C2,D3 offset:4 at gate B: source:A1 destination:C2 route:B2,D3 offset:8 at gate C: source:A1 destination:D3 route:B2,C3 offset:12 The source host's IP address never changes; the only addresses that change are the intermediate addresses and the destination address. The idea behind replacing the source route addresses with the recorded route addresses is that the IP packet doesn't change size when it passes through a gateway. It also preovides the destination host with an (albeit reversed) route back to the source host. The offset pointer tells each gateway where to insert its recorded route address. When the packet arrives, the destination host flips the route around, removes the first hop on the route and makes it the destination, and adds the final destination host as the last hop on the route. It also resets the offset value to 4. Host D3 goes through the following machinations before sending a packet back to A1: source route flipped, offset set to 4: source:D3 destination:<NULL> route:C3,B2 offset:4 first hop removed and made destination: source:D3 destination:C3 route:B2 offset:4 final destination added to route: source:D3 destination:C3 route:B2,A1 offset:4 This is the packet that is sent out. Hope this was of some help (and that I got it right :-) MarkL Internet: markl@jhereg.lcs.mit.edu MIT Laboratory for Computer Science Distributed Systems Group ---------- "...the MGA 1600 Mk-II: Precision sports motoring in the MG racing tradition..."
brescia@CCV.BBN.COM (Mike Brescia) (10/07/86)
Steve,
The following points are important:
- the IP source field remains constant, so that the higher level protocol can
ignore the recorded route
- the IP destination field reflects the current goal, and not the ultimate
destination, until the source route has been consumed
- the offset includes the first 3 bytes and is zero-based. "... the smallest
legal value for the pointer is 4."
host A gate B gate C host D
+------+ +------+ +------+ +------+
| | | | | | | |
| A1|-------->|B1 B2|-------->|C2 C3|-------->|D3 |
| | net 1 | | net 2 | | net 3 | |
+------+ +------+ +------+ +------+
(..host..) source:A1 destination:B1 route:B1,C2,D3 offset:4
on net 1: source:A1 destination:B1 route:A1,C2,D3 offset:8
on net 2: source:A1 destination:C2 route:A1,B2,D3 offset:12
on net 3: source:A1 destination:D3 route:A1,B2,C3 offset:16
What you show is the way TOPS20 has implemented it, where host A has put a
record of its outgoing interface into the packet. The unix implementations
do not do this, and the source route option only has 2 hops.
Here is an example of unix flavor source routed packet, with an octal dump of
the packet on the way out of teh source host, and another on receipt at the
destination (the same host in this case). Note also the extra pad (1) option.
A1=10.2.0.82
B1=10.2.0.5 B2=128.89.0.5
C2=128.89.0.4 C3=10.3.0.82
D3=10.2.0.82
Outgoing packet:
110 0 0 54 0 0 100 0 31 24
263 53 12 2 0 122 12 2 0 5
1 203 13 4 200 131 0 4 12 2
0 122 1 226 0 0 0 0 0 305
147 244 226 0
Incoming packet:
110 0 0 54 0 0 100 0 27 24
264 324 12 2 0 122 12 2 0 122
1 203 13 14 200 131 0 5 12 3
0 122 1 226 0 0 0 0 0 305
147 244 226 0 tcp-ip-RELAY@SRI-NIC.ARPA (William Morgart) (10/09/86)
After reading the previous messages on IP routing options I thought I'd mention a few problems with those messages. All of the problems are caused by the differences between RFC791, The DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military Standard Internet Protocol. The earlier messages stated that the destnation address in the IP header is changed at intermedate gateways that are in the source route list. This is only true if the IPs are implemented according to the RFC. If the IP was implemented following the MILSTD, it will not change the header. This is a little gotcha that must be watched since an implementation meant for the DoD world of MILNET will be required to meet the MILSTD and not the RFC. Another gotcha also relating to options processing is what options are copied on fragmentation. In the RFC the "Loose Source and Record Route" option is specified as being copied while in the MILSTD it isn't copied. Even the MILSTD is confused on this point since it defines the most significant bit of the option to be the copy flag and the option type for LSRR is 0131 (octal) though the text in the MILSTD specifies that LSRR isn't copied. Next, the security option as specified in both the RFC and the MILSTD has been superseded by a new security option developed by the IPSO Working Group in early 1985. A document describing the new option should be available for DCA or DDN. Finally, a comment for thought: since DoD via DARPA is paying for the ARPANET and MILNET plus requiring that MILNET use the MILSTD verison of IP, the ARPANET side of the world should think about using the MILSTD version also. If this doesn't happen the two sides won't be able to interoperate. Bill Morgart bmorgart@mitre-gateway.arpa Phone: (703) 883-6554
brescia@CCV.BBN.COM (Mike Brescia) (10/09/86)
(from bmogart@mitre)
All of the problems are caused by the differences between RFC791, The
DARPA Internet Protocol Specification, and MILSTD-1777, The DoD Military
Standard Internet Protocol.
My understanding of mil-std-1777 was that it recast the darpa IP spec in
mil-std terminology. I thought that there was no intent to change the spec,
or cause disinteroperability. I would be interested in hearing if anyone has
implemented the mil-std spec /in vacuo/ and expected that implementation to
talk to any existing host, or pass packets through any existing gateway.
MikeProvan@LLL-MFE.ARPA (10/10/86)
there is an errata sheet on the Milspec for IP which corrects exactly these problems. unfortunately, i don't remember where it is or even whether it's been officially released. since there are bugs in the Milspec that appear to me to prevent actually implementing it, i don't think there's too much worry about someone implementing it in a vacuum.