On Jun 26, 2022, at 02:46, steve jenkin
<sjenkin(a)canb.auug.org.au> wrote:
One of the modern challenges for Enterprise Customers is “change network provider”.
One major Aussie firm just took two years to move Service Provider and it was ’news’.
25yrs ago, and probably now as well, interconnecting / splitting corporate networks
following merges / de-merges was a huge task.
IP networks require re-numbering and basic IP services, like DNS, email, web, need
re-provisioning / re-platforming.
I take issue with this, and have experience to backup my view: it is not hard to change
Internet Service Providers (ISP) for large corporations - I did it several times during my
tenure as the “Internet guy” for Apple Computer, Inc., an ~$8bn revenue multinational
corporation. You just have to plan for it properly, handle transitions gracefully
(ideally, with overlap), and keep control of (do not outsource) key assets like domain
names, public IP network address assignments, and services like e-mail (SMTP).
Apple's primary “face” to the world in July 1988 when I arrived was a DEC VAX-11/780
running 4.3 BSD Unix. I renumbered it once, when we changed from CSNET’s X25NET (9.6Kb/s
IP-over-X.25 via TELENET/SPRINTlink) to a 56Kb/s (DS0) leased line - we started using an
assigned class B network: 130.43/16 - the VAX became 130.43.2.2. It retained its name as
“apple.com” until it was decommissioned in the late 1990s.
Apple was on CSNET primarily (where the VAX was connected), and had a separated BARRNET T1
that belonged to the A/UX group (A/UX was Apple’s version of Unix). I connected our two
external “perimeter” networks , set up fail-over IP routing (initially with RIP (ugh),
later deployed BGP), upgraded CSNET in California, added a second site in Cambridge, MA to
CSNET, later moved Cambridge to NEARNET, replaced CSNET in California with CERFNET, helped
our European offices in Zeist, NL connect to SURFnet, and our customer service division in
Austin, TX to SPRINTNET (they had to forcibly (disruptively) renumber, but they screwed up
by not listening to me during their network planning).
We did have to clean up an internal IP address mess when I got there: lots of “picked out
of the air” net numbers in use: 90/8, 92/8, 95/8, etc.; those were all renumbered into
properly assigned net 17/8, which Apple still uses today.
Before the WWW, “ftp.apple.com” offered up MacOS software distribution via anonymous FTP
from a Mac IIcx running A/UX under my desk, and to prevent our connectivity from being
overwhelmed when MacOS releases were published, I wrote an ftp-listener to restrict the
number of FTP connections per peer classful network number for that server. I later
installed that code at the Smithsonian Institution on a Unix machine they set up for
public anonymous FTP of their digitally-scanned historical photography archive, because
they had the same problem: limited connectivity, popular content.
As for mergers, acquisitions, and spinoffs, I was involved in networking for Coral
Software (acquired; purveyors of Macintosh Common Lisp) which became Apple Cambridge;
Taligent which was an Apple/IBM joint venture (an Apple OS & software group spin-out;
they were set up with a separate public class B network number and domain name from the
get-go to provide for maximum future flexibility, even though they were initially in a
building on the Apple Campus in Cupertino, CA and thus on the dark fiber plant, and Apple
(me) was their ISP) and ultimately IBM bought out Apple; The Apple Engineering secured
connection to the “Somerset Design Center” in Austin, TX (a joint venture between Apple,
IBM, and Motorola (the AIM alliance) from whence the PowerPC processor came), which was
tricky.
I’ll grant that when I was doing this work, Internet connectivity downtime didn’t mean
immediate revenues losses (e.g., from not being able to accept orders in the Apple Online
store, which did not (yet) exist), but e-mail was critical to Apple’s world-wide
operations, and making e-mail robust & reliable was the first job I was hired to do:
fix sendmail(8), take control of DNS (CSNET controlled the
apple.com zone file when I
arrived), and naturally, that extended to making Internet connectivity & routing
robust as well.
The main problem that “modern” mergers & acquisitions face in coordinating networking
is a direct result of something else I fought against in the IETF: private IP address
space (RFC 1918), and Network Address Translation (NAT) - see RFC 1627. Unfortunately, I
and my colleagues lost that debate, which is why one now sees double/triple NAT setups to
try and make overlapping private IPv4 addressed networks talk to each other. You’ll notice
that I eschewed use of private address space while at Apple, and having unique public IP
address space made most things simpler - funny how following the architecture works better
than fighting it.
Unix is tied into all of this because it has been the platform where (most often) the
first implementation of many of these protocols or hacks is written. It takes a flexible
operating system to make such a wide range of applications possible. However, properly
setting up the rest of the communications infrastructure (in which Unix must communicate)
is important too.
Erik Fair