[TUHS] Research Datakit notes

[Erik Fair]

> On Jun 26, 2022, at 02:46, steve jenkin <sjenkin at 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