summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc831.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc831.txt')
-rw-r--r--doc/rfc/rfc831.txt355
1 files changed, 355 insertions, 0 deletions
diff --git a/doc/rfc/rfc831.txt b/doc/rfc/rfc831.txt
new file mode 100644
index 0000000..6774701
--- /dev/null
+++ b/doc/rfc/rfc831.txt
@@ -0,0 +1,355 @@
+
+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]