Backup access to the European side of SATNET
Using IP source routing to reach Europe when a satellite link fails.
Braden, R.T., "Backup access to the European side of SATNET", RFC 831, DOI 10.17487/RFC0831, December 1982, <https://www.rfc-editor.org/info/rfc831>.
@misc{rfc831,
series = {Request for Comments},
number = 831,
howpublished = {RFC 831},
publisher = {RFC Editor},
doi = {10.17487/RFC0831},
url = {https://www.rfc-editor.org/info/rfc831},
author = {R.T. Braden},
title = {{Backup access to the European side of SATNET}},
pagetotal = 6,
year = 1982,
month = dec,
} RFC text
Contents
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
Backup Access to the European Side of SATNET
Robert Braden
DISCUSSION
The purpose of this RFC is to focus discussion on a
particular Internet problem: a backup path for software
maintenance of the European sector of the Internet, for
use when SATNET is partitioned. We propose a
mechanism, based upon the Source Routing option of IP,
to reach European Internet sites via the VAN Gateway
and UCL.
This proposal is not intended as a standard at this
time.
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
1. Introduction
During several previous SATNET meetings, it has been
observed that it would be useful for BBN to be able to
access the European side of SATNET indirectly via the VAN
Gateway, when direct SATNET connectivity has been lost.
This short paper proposes a possible approach to such
"backup" access, using the source routing option of IP.
Figure 1 illustrates the problem we wish to solve. The US
host H is used for diagnosis and control of the SATNET
SIMP's S1 and S2 as well as the gateways B and G and the UCL
TAC (not shown, but connected to G).
SATNET
(partitioned)
ARPANET/SATNET __ __ UCL
Gateway Simp ( \ \ ) Simp Gateway
____ ___( / / )____ ____
| B |__| S1 | \ \ | S2 |________| G |_____ rsre
|____| |____| / / |____| |____|
| ( \ \ ) |
| (__ / /__) _______|____
________|____ ( )
( ) ( )
( ARPANET ) ( UCL NET )
( ) ( )
(_____________) ( )
| | (_____________)
__|_ | VAN/ .
| H | | Public Data Nets .
|____| | _____________ .
Diagnostic | ( ) .
Host __|__ ( VANNET ) _.___
| VAN |* * (* * * * * * * * *)* * * * | |
| gw------(--- IP Tunnel -----)--------| U |
|_____|* * (* * * * * * * * *)* * * |_____|
VAN ( )
Gateway (_____________)
Figure 1. US/UK Connectivity with Partitioned SATNET
RFC 831 - 1 - [Braden]
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
VANgw is the VAN Gateway which encapsulates IP datagrams in
X25 packets for transmission over VAN/PTT virtual circuits.
The collection of these paths, called "IP tunnels" by UCL,
is addressed from the Internet as a distinct network,
VANNET.
U is a UCL host, the Terminal Protocol Converter, which
provides a path to UK X25 networks. However, to the Internet
world U looks like a host on VANNET, so the path from U to
UCLNET (shown dotted) does not appear to exist.
Now suppose SATNET is partitioned between S1 and S2. Then
we wish host H to be able to exchange IP datagrams with S2
via the "back door" path:
H - Internet - VANgw - VANNET - U - UCLNET - G - S2
There are some important rules in this game, however.
(1) U may only be a host, not a gateway.
This is because we do not want the Internet to route
ALL its traffic (e.g. rsre traffic and UCL traffic
that is required to use SATNET) via the IP Tunnel.
So the VAN Gateway (VANgw) must not discover it can
get to UCLNET through U.
(2) To implement the back door path to S2, we are
willing to have some special code in H and/or in U,
but not in G, S2, or VANgw.
Note: Jack Haverty is allowed to violate this
assumption, though we doubt that he will want to.
But we must stick to it.
Given these constraints, we claim that the only possible
solution is to "mung" the headers of IP datagrams at UCL.
Thus, when SATNET is partitioned:
(1) The IP addresses of S2, G, and the UCL TAC are
unreachable from all US gateways. Therefore, if H
sends a packet addressed to one of these
destinations, it will be discarded and an ICMP
unreachable message returned.
RFC 831 - 2 - [Braden]
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
(2) Similarly, the IP address of H is unreachable from
the UK side. Hence, if the XNET debugger in a UK
host emits a return packet addressed to H, that
packet will be dropped.
Therefore, the destination address of each packet from H
must be changed in order to reach the UCL side of SATNET (S2
or G), and the source address of each of these packets must
be changed so that return packets can reach H. For this
purpose, we introduce the Munger host M (see Figure 2).
SATNET
(partitioned)
BBN __ __ UCL
Gateway Simp ( \ \ ) Simp Gateway
____ ___( / / )____ ____
| B |__| S1 | \ \ | S2 |________| G |_____ rsre
|____| |____| / / |____| |____|
| ( \ \ ) |
| (__ / /__) _______|____
________|____ ( )
( ) ( )
( ARPANET ) ( UCL NET )
( ) ( )
(_____________) ( )
| | (_____________)
__|_ | |
| H | | Public Data Nets |
|____| | _______________ _|___
Diagnostic | ( ) | M1 |
Host __|__ ( ) |:::::|
| VAN |* * (* * * * * * * * * *) * * |:::::|
| gw------(--- IP Tunnel -----)------------| M2 |
|_____|* * (* * * * * * * * * *) * * |_____|
VAN ( VANNET ) M
Gateway (_______________) "Header
Munger"
Figure 2. Introduction of Header Munger at UCL
Host "M" (M1/M2) is mulit-homed, appearing as host M2 on
VANNET and as host M1 on UCLNET. Like host U (shown in
Figure 1), host M2 is the end of an IP Tunnel which
communicates with VANgw over an X25 virtual call.
RFC 831 - 3 - [Braden]
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
Suppose for example that host H desiollege London
December 1982
Suppose for example that host H desires to reach the XNET
debugger in the SIMP S2. H must send its packets with
destination address M1; these will be routed to M1 via VANgw
and the IP Tunnel. Host M will change the headers of these
datagrams to contain source address M1 and destination S2.
S2 will return packets to M1, and M1 will change them back
to M2->H packets and launch them back through the VANNET to
H.
How does M know how to change the headers?
(1) M could respond to a range of M1 and M2 addresses,
and have a fixed table of correspondence.
(2) We propose instead to use the SOURCE ROUTING option
in the datagrams. This assumes that H is able to
build source-routed datagrams, and is not upset that
the intermediate host in the route is not a gateway.
If we further assume that the IP layers in G and S2
can handle source and return routes, then the task
is simple. M must contain the source routing
algorithm of a gateway, but otherwise act as two
hosts (no routing updates, etc).
(3) Although G supports source routing, S2 and the TAC
may not. In that case, S2 and the TAC will not be
able to recognise the return route in a received
packet and use it as a source route in packets sent
in reply.
This possibility calls for additional complexity in
M, a combination of (1) and (2):
* In the US -> UK direction, the Source
Routing option would be used.
* In the reverse direction (UK -> US),
mapping of datagram addresses would be
controlled by a table in M.
RFC 831 - 4 - [Braden]
Network Working Group R. Braden
Request for Comments: 831 University College London
December 1982
We suggest that M use source routing to get packets
from H to S2, and meanwhile build a "soft state"
table showing this mapping. When a packet comes
from S2 without source routing, M would consult this
soft state table to discover how to alter the
addresses to reach H again. This would allow only
one US host at a time to access a given SATNET host,
but surely this is no restriction.
In practice, M2 and U should have different IP tunnels and
hence different DTE addresses. Since the caller pays the
X25 charges, the IP Tunnel for U will normally be opened
only by UCL. On the other hand, the IP Tunnel to M2 will be
opened from the US end. Since UCL has only one PSS line,
this requires the use of separate X25 subaddresses. The VAN
gateway must handle 14 digit X121 addresses, as well as 12
digit addresses.
2. Acknowledgment
Robert Cole of UCL has made major contributions to the
contents of this paper. In particular, he suggested the use
of the Source Routing option.
RFC 831 - 5 - [Braden]
AI ELI5
On this page
§1The Problem: SATNET Partitioning
SATNET is a satellite network connecting ARPANET in the US to European internet sites. BBN (Bolt Beranek and Newman) operates diagnostic and control hosts that manage SATNET's satellite interface modules (SIMPs), gateways, and equipment on the European side. When SATNET becomes partitioned—for example, if the satellite fails or communications break between the two sides—these European devices become unreachable.
The US diagnostic host H cannot send packets addressed to European hosts because routing tables mark those addresses as unreachable. Similarly, European hosts cannot send reply packets back to H. Direct SATNET connectivity is essential for remote diagnostics, monitoring, and control of critical network infrastructure, so losing this path during a failure is a serious problem.
The solution must allow H to reach SATNET devices in Europe via an alternative path while respecting constraints: the VAN Gateway must not learn routes through Europe that would cause normal internet traffic to use the backup path, and the solution should avoid modifying gateways on either end.
When the satellite breaks, the diagnosis host can't reach European machines. Normal routing rules prevent it from trying the backup path because Europe is marked unreachable. We need a special way to send messages through the back door without confusing regular internet routing.
§2Header Munging with Source Routing
The proposal introduces a header munger host M at UCL (University College London). Host M is multi-homed, appearing as M2 on VANNET (a network that uses X.25-based IP tunnels) and as M1 on UCLNET (the local network). The diagnostic host H sends packets destined for European SATNET equipment to M1 instead, using source routing to specify the path through the VAN network.
Host M receives these source-routed packets, rewrites their headers to point to the actual destination (S2, the SATNET SIMP on the European side), and forwards them. When S2 returns a reply, M intercepts it, rewrites the source and destination addresses back to M1 as the intermediate host, and sends it back through VANNET to H.
The key insight is using the IP Source Routing option to tell M exactly how to transform packet headers. H builds a source route that includes M1 as an intermediate hop, rather than a gateway. Since the RFC specifies that source routing can use non-gateways as intermediate hops when both endpoints handle source routing, this works even though M is acting as a host, not a true router.
The munger host is like a mail forwarding service. US packages arrive addressed to the munger's address on the satellite side, the munger changes the address label to the real European destination, forwards the package, and changes return addresses so reply packages find their way back to the US.
- Source-routed packet (dest=S2, via M1)Illustrative, not from the RFC
- Rewritten packet (dest=S2, from M1)
- Reply (from S2, to M1)
- Rewritten reply (from M1, to H)
§3Implementation Complexity and Soft State
The simplest implementation assumes all hosts (H, S2, and the gateway G) support IP source routing. H builds source-routed packets with M1 as an intermediate hop, and M uses the source routing algorithm to extract the return route, rewriting headers in both directions based on this route.
However, S2 and the TAC may not support source routing. In that case, a more complex approach is needed. M uses source routing for packets traveling from US to UK (to ensure proper delivery), but relies on a soft state table for the reverse direction. When a source-routed packet arrives at M from H, M records the mapping of (source H) to (M1) in an ephemeral table. When S2 sends a reply without source routing, M consults this table to map addresses back, allowing the reply to reach H through the VANNET tunnel.
This soft state approach allows multiple diagnostic sessions but only one US host at a time per SATNET destination. M tracks active mappings and uses them only as long as traffic continues; if the session ends, the mapping expires.
The munger host is smart enough to handle two cases. If the European side understands source routing, it's easy: tell it the return path. If not, the munger remembers "when I see packets from Europe about this connection, send them back to the US diagnostic host."
§4VANNET and X.25 Infrastructure
VANNET is a collection of IP tunnels that encapsulate IP datagrams in X.25 packets for transmission over VAN (Value Added Network) and PTT (Postal, Telegraph, Telephone) virtual circuits. These tunnels are addressed as if VANNET were a distinct internet network. The VAN Gateway (VANgw) encapsulates IP traffic into X.25 and manages connections to VANNET.
Host U at UCL is the Terminal Protocol Converter, appearing to the internet as a host on VANNET but actually connecting to UK X.25 networks. The path from U to UCLNET (shown in the RFC as dotted) does not officially exist from the internet's perspective, preventing general internet routing through U.
M2 and U each have different IP tunnels through different X.25 virtual circuits. U's tunnel is typically opened by UCL (the receiver pays for X.25 charges), while M2's tunnel can be opened from the US. Both must have separate X.121 addresses on the PSS (Packet Switched Service) line, using X.25 subaddresses to distinguish them. The VAN gateway handles both 14-digit and 12-digit X121 addresses for this purpose.
VANNET is like a special parcel service that uses X.25 connections instead of direct internet routes. The munger and the protocol converter each have their own accounts with this service, so packets can flow through them independently.