Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Stefan Skoglund via cctalk]

mån 2018-02-05 klockan 10:31 -0700 skrev Grant Taylor via cctalk:
> On 01/18/2018 12:23 PM, Dennis Boone via cctalk wrote:
> > You all talk about Proxy ARP in the past tense for some reason. :)
> 
> You might find it entertaining to know that I was just talking with 
> colleagues that are currently using Proxy ARP to solve the lack of 
> subnet problem at 40 Gbps line rate.
> 
> It's the same old problem, but this time it's how to sub-divide a
> /26 
> into a /27 and two /28s without the router for the /26 being re-
> configured.
> 
> So Proxy ARP FAR from dead.

hostapd in some configurations does that ie proxies arp on the
behalf of a phone for example.

virtual switches can i believe be configured in a proxy arp
configuration ie the host's OS proxies arp request from a
switch/router.

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 12:23 PM, Dennis Boone via cctalk wrote:

You all talk about Proxy ARP in the past tense for some reason. :)


You might find it entertaining to know that I was just talking with 
colleagues that are currently using Proxy ARP to solve the lack of 
subnet problem at 40 Gbps line rate.


It's the same old problem, but this time it's how to sub-divide a /26 
into a /27 and two /28s without the router for the /26 being re-configured.


So Proxy ARP FAR from dead.



--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/19/2018 01:25 AM, Christian Corti via cctalk wrote:
Why do you want to convert between the two frame types? They can happily 
coexist on the same segment. In fact I'm using this setup on some Linux 
servers that provide both ordinary IP services (like NFS) and Novell 
shares (using Mars NWE) for DOS clients - on the same interface.


My intention was to allow IP running on top of something other than 
Ethernet II to be able to communicate with IP on top of Ethernet II. 
Preferably via a router and not some sort of bump in the wire frame 
conversion.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Christian Corti via cctalk]

On Thu, 18 Jan 2018, Grant Taylor wrote:
I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
a router to convert from one Ethernet frame type to another Ethernet frame 
type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.


Why do you want to convert between the two frame types? They can happily 
coexist on the same segment. In fact I'm using this setup on some Linux 
servers that provide both ordinary IP services (like NFS) and Novell 
shares (using Mars NWE) for DOS clients - on the same interface.


Christian

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:39, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 11:33 AM, Noel Chiappa via cctalk wrote:
>> E.g. it probably only supports class A addresses, for instance, which is 
>> going to influence the code for picking the first-hop router.
> 
> I was not aware that there was code that supported /only/ Class A (/8) 
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
> 
> I /thought/ that everything was either classful (as in supports all three 
> classes: A, B, and C) or classless (as in supports CIDR).
> 
> Is my networking history missing something else?

In the course of this discussion I have been reminded that BBN did a TCP/IP for 
the HP3000 that ran under MPE IV. It is described in IEN 167 and if you read 
that carefully you will realize that they got started on MPE III; MPE message 
files (think record-structured pipes) first appeared in late MPE III but were 
not documented until MPE IV.

Trawling the Intertubes for, well, anything about this I turned up a sort of 
progress report.



It begins on page 66 of 81, on page 68 of 81 it describes changes to the 
routing table.  "Currently, this table has one entry for each of the possible 
256 networks, and accesses are very fast." and I'll just leave you with that.

-Frank McConnell

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:27, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
>> So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
>> (V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late 
>> enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before 
>> which could only do IEEE over 802.3).  And it has an FTP client.
> 
> Please clarify what you mean by "IP over Ethernet", specifically what frame 
> type?
> 
> Are you talking about Ethernet II frames?

What I meant to write in that latter part was "IP over IEEE 802.3".  HP's LAN 
business started out big on big-S Standards, as in an IEEE Standard was 
preferred over a document circulated by three other computer companies.  That 
document would be Ethernet II.  So HP's initial attempts at TCP/IP were done 
with IEEE 802.2 framing and SAP 6, and used HP’s Probe protocol for local 
address discovery.  And TCP/IP was done as a stopgap, the stated plan was to 
support the OSI stack when it was ready.

HP did eventually (by the end of the 1980s) come to grasp that the customers 
really wanted Ethernet (II) so they could at least ping the 3000 to see if it 
was up.  Support for that (and ARP) arrived in the version of NS Transport for 
MPE V/E V-delta-5.

>> So you might think I'd be able to move files between it and a modern FreeBSD 
>> box, right?  I mean, it's all just Ethernet, right?
> 
> Ethernet != Ethernet

OK, "IP over Ethernet II".  But most folks these days won’t be thinking about 
the other kinds.  Maybe even most folks on this list.

> I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
> a router to convert from one Ethernet frame type to another Ethernet frame 
> type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.

If you want something that was correct for the period, use a Cisco AGS router.  
(I think later Cisco routers will do too.)  It can do the routing and can also 
proxy HP’s Probe address-resolution protocol.

The Wollongong Group had a software routing product, WIN/ROUTE, and they worked 
it over a bit to make another product WIN/ROUTE2 which could do the 
802.3/Ethernet routing.  Can't remember whether it required 3C503 cards.

> I actually don't know if Linux can do this or not.  My typical go to tool 
> might not help here.  :-/
> 
>> Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") 
>> in V-delta-9 and before, such that it tears down the connection with a 
>> failure if a packet is received with IP type-of-service not zero. And the 
>> FreeBSD FTP server sets a socket option that gets FreeBSD to send that sort 
>> of packet.
>> At a previous employer, I went round with HP a bit on behalf of a mutual 
>> customer and got HP to issue a patch for NS Transport that corrects this 
>> behavior on the MPE side.  Clearly, I don't have that patch on this system.
> 
> I think we all have experiences like that.  Some sort of custom code that we 
> didn't care about at the time (beyond fixing the problem) that we would now 
> like to get our hands on years later.

Upgrading to MPE Release 40 FOS with Platform 3P SUBSYS would do; the patch did 
make it into later releases of NS Transport (which would be on the SUBSYS tape).

>> FreeBSD is FreeBSD, and I can build its FTP server from source and change it 
>> so it works in this situation; but I think this should give y'all some idea 
>> of the hilarity that can ensue when you exhume a 1980s TCP/IP and put it on 
>> your network.
> 
> I wonder if there are other tricks that can be used to work around this 
> without needing to recompile services.  I.e. use IPTables (or FreeBSD's 
> counterpart that I don't know the name of) to change the type-of-service to 
> something other than 0.

Been a while since I did that sort of thing but it was with ipfw, a divert 
socket, and a program to modify the diverted packets and hand them back down to 
the kernel.

Really, commenting out the setsockopt() call in ftpd seemed the easiest thing 
to do at the time, but I’d need to do it over now and might go for this sort of 
approach.

> Here's a link with a lot of gory details on NetWare's support of multiple 
> Ethernet frame types.
> 
> Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
> - https://support.novell.com/techcenter/articles/ana19930905.html
> 
> Here are the four frame types that NetWare supports:
> 
> - Ethernet II
>- I think this is what we are using for just about everything today.
> - IEEE 802.3 "raw"
>- I'm speculating that this is the frame type that Frank is referring to 
> above.
> - IEEE 802.3 with 802.2
> - IEEE 802.3 with 802.2 SNAP
> 
> I /think/ that NetWare can bind IP to all four Ethernet frame types. 
> Hopefully one of them is compatible with V-delta-4 and before.

If it can, I think you want the "IEEE 802.3 with 802.2" on the HP side, and the 
"Ethernet II" on the 

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 12:53 PM, Eric Smith via cctalk wrote:
Proxy ARP is (or was, at the time) something that had to be configured 
for individual IP addresses or ranges. What I did was have it reply to an 
ARP for any IP address outside the subnet(s) configured on that interface.


Intriguing.

I guess this means that you only heard ARP requests for IP addresses 
that other systems in the same broadcast domain thought were local to 
said broadcast domain.


You wouldn't need to worry about errant ARP requests for things outside 
of the local subnet as that would go through the default gateway (or 
other defined router).


I like it.


Yes. Specifically IPv4.


*nod*

The point of bozo-arp and anyipd was that the only necessary configuration 
was to turn it on. Of course, there may be scenarios in which one does 
not want the router to respond to bogus ARP requests, in which case 
bozo-arp/anyipd should not be used.


Like all tools, you have to be careful where you do use it.  -  I'd 
default with it off (or not installed) and  turn it on as necessary.




--
Grant. . . .
unix || die

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Eric Smith via cctalk]

On Thu, Jan 18, 2018 at 11:35 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> On 01/18/2018 11:00 AM, Eric Smith wrote:
>
>> Years ago I added a configurable "bozo-arp" feature to the Telebit
>> NetBlazer router, which would respond to ARP requests for non-local
>> addresses and reply with the router's MAC address (on that interface),
>> specifically in order to make classful-only hosts work on a CIDR network.
>>
>
> That functionality sounds exactly like my understanding of what Proxy ARP
> is supposed to do.
>

Proxy ARP is (or was, at the time) something that had to be configured for
individual IP addresses or ranges. What I did was have it reply to an ARP
for _any_ IP address outside the subnet(s) configured on that interface.

Since you stated that anyipd "…would respond to ARP requests for non-local
> addresses…" I"m assuming that you are talking IP and not another protocol.
>

Yes. Specifically IPv4.

Recently I've needed that functionality on Linux, as I have multiple old
>> systems that only understand classful, including the AT UnixPC (7300 or
>> 3B1). I suppose I should rewrite and open-source it.
>>
>

> I /think/ (it's been too long since I've done this) that you would
> configure one classless interface with 10.20.30.254/24 and another
> classless interface with 10.10.10.254/24 -and- enable Proxy ARP on both
> (?) interfaces.  You will likely need to enter the target machine's IP
> addresses in a file that the Proxy ARP sub-system references to learn what
> target IPs that it needs to Proxy ARP for.
>

The point of bozo-arp and anyipd was that the only necessary configuration
was to turn it on. Of course, there may be scenarios in which one does not
want the router to respond to bogus ARP requests, in which case
bozo-arp/anyipd should not be used.

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 12:23 PM, Dennis Boone via cctalk wrote:

You all talk about Proxy ARP in the past tense for some reason. :)


Please don't interpret the fact that I am inadvertently talking about 
Proxy ARP in the past tense to mean anything.


I personally started solving the problem that Proxy ARP is meant to 
solve with a different solution.


I fell in love with Linux bridges (brctl, etc) for things like this (I'm 
guessing) 15+ years ago.  I can create a Bridging Router (a.k.a. 
BROUTER) that combines layer 2 and layer 3 functionality.  This allowed 
me to bridge non-IP protocols, like NetBIOS / IPX, while routing IP.


I could further extend things to include selectively bridging IP via 
adding EBTables to the mix.


I did a LOT of crazy things with Linux bridges.  }:-)

In hind sight, Proxy ARP might have been the simpler solution.  Though I 
think Proxy ARP would have required that I configure IPs to be Proxy 
ARPed on all intermediate hosts.  Where as bridging has it's own 
inherent L2 learning.  (At least when I was working with non-IP protocols.)


I don't know how well Proxy ARP plays with things like OpenVPN or 
OpenSSH layer 2 tunnels.  -  I know that I can easily extend layer 2 
across a LARGE majority of networks using Linux bridges.  -  I think 
that I can even bridge any type of network that uses 802.2 Link Level 
Control headers.  I.e. Token Ring (802.5) and Ethernet (802.3) and 
Wireless (802.11) and various tunnels.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Phil Budne via cctalk]

Noel wrote:
> but I dunno how one would hook _that_ simulation up to a simulated host
> running a simulated ARPANET interface.

It would seem silly to simulate a bit by bit interface, so just come
up with an encapsulation of 1822 messages in TCP?

Two-octet count(*), plus 1822 leaders .

(*) and if any out-of-band signals are required maybe some flag bits?

And if hooking up a network of simulated IMPs gets old, you could
write a single ARPAnet server program that multiple hosts connect to

Mr DeMille; RFNM

p

Re: Reviving ARPAnet

[Charles Anthony via cctalk]

On Thu, Jan 18, 2018 at 10:27 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Grant Taylor
>
>
> The ARPANET supported several different kinds of interfaces between the
> IMPs
> (the switching nodes in the ARPANET) and hosts, but the 'usual' one was
> either 'Local Host' (LH) or 'Distant Host' (DH) which were _basically_
> identical except at the very lowest level - LH was TTL, and DH was
> differential pair.
>
> Those interfaces were a custom bit-serial thing with a handshake (with
> "there's-your-bit", "ready-for-next-bit" lines, etc); see BBN Report #1822:
>
>
And an "end-of-packet" bit.


>   http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf
>
> So the "ARPANET interface" in the host is a piece of custom hardware (some
> were DMA; I also used one which was interrupt per byte) which went on the
> host, which talked 1822 (as it was called), of either the DH or LH physical
> form.
>
>
>
> > Do the necessary emulators support the ARPANET interface?
>
> Dunno, but they shouldn't be too hard to add.
>
> The real problem is going to be 'what do you hook the simulated ARPANET
> interfaces up to, and how'? I know they have IMP code running in
> simulators:
>
>   http://mailman.trailing-edge.com/pipermail/simh/2013-
> November/007672.html
>
> but I dunno how one would hook _that_ simulation up to a simulated host
> running a simulated ARPANET interface.
>
>
The IMP emulator emulates the DH/LH interface with UDP packets. I wired up
the dps8/m emulator to the IMP emulator, but I don't have the ARPAnet stack
for Multics, so it's just packets.

-- Charles

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Dennis Boone via cctalk]

 > > which would respond to ARP requests for non-local addresses and
 > > reply with the router's MAC address (on that interface),
 > > specifically in order to make classful-only hosts work on a
 > > CIDR network.

 > Yeah, Proxy ARP (an early RFC here:

You all talk about Proxy ARP in the past tense for some reason. :)

De

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Noel Chiappa via cctalk]

> From: Eric Smith

> which would respond to ARP requests for non-local addresses and reply
> with the router's MAC address (on that interface), specifically in
> order to make classful-only hosts work on a CIDR network.

Yeah, Proxy ARP (an early RFC here:

  https://www.rfc-editor.org/rfc/rfc1027.txt

but IIRC it was people at CMU who first came up with the idea; this RFC is
from people at UT-Austin, documenting it) was originally done to support
subnetting (see

  https://www.rfc-editor.org/rfc/rfc917.txt

for more) when it was first introduced - for hosts for which people didn't
have the source, but needed to attach it to a subnetted network.

Subnetting was a stage before CIDR (which took subnetting and Carl-Herbert
Rokitansky's 'supernetting' and mushed them together).

Noel

Re: Reviving ARPAnet

[Lars Brinkhoff via cctalk]

Grant Taylor wrote:
> Do the necessary emulators support the ARPANET interface?

Ken Harrenstien's PDP-10 emulator does.  ITS uses the IMP interface for
TCP/IP to this day.

Re: Reviving ARPAnet

[Warner Losh via cctalk]

On Thu, Jan 18, 2018 at 11:27 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:
>
> Easier, to get this old TCP/IP running, might be to write a Unix V6 driver
> for
> an Ethernet card (one the simulators do support - I know Ersatz-11 does the
> Interlan NI1010A/2010A, which is nice and simple) and write an Ethernet
> network interface module for that TCP, which talks to said driver; i.e.
> just
> replace the ARPANET interface stuff completely.
>

That's what I had thought about maybe doing... As well as playing with a V7
port  in my copious spare time

Warner

Re: IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Grant Taylor via cctalk]

On 01/18/2018 11:00 AM, Eric Smith wrote:
Years ago I added a configurable "bozo-arp" feature to the Telebit 
NetBlazer router, which would respond to ARP requests for non-local 
addresses and reply with the router's MAC address (on that interface), 
specifically in order to make classful-only hosts work on a CIDR 
network.


That functionality sounds exactly like my understanding of what Proxy 
ARP is supposed to do.


Later someone paid me to write a NetBSD daemon ("anyipd") to do the same 
thing, though for an entirely different reason.


Nice.

Since you stated that anyipd "…would respond to ARP requests for 
non-local addresses…" I"m assuming that you are talking IP and not 
another protocol.  Please correct me if I'm assuming incorrectly.


Recently I've needed that functionality on Linux, as I have multiple 
old systems that only understand classful, including the AT UnixPC 
(7300 or 3B1). I suppose I should rewrite and open-source it.


I'm trying to make sure that I understand what you're wanting / needing 
to do and evaluate if Proxy ARP can do it or not.


I'm guessing that you have a host, AT Unix PC, that's at (for the sake 
of discussion) 10.20.30.40/8 and you'd like to communicate with another 
machine that's at 10.10.10.10/24.  Obviously 10.10.10.10/24 is a subset 
of 10.0.0.0/8, so the AT Unix PC thinks that 10.10.10.10 is local.  - 
Does this accurately represent your use case?


Unless you correct me, I'm going to assume that this is accurate enough 
for the sake of discussion.


I /think/ (it's been too long since I've done this) that you would 
configure one classless interface with 10.20.30.254/24 and another 
classless interface with 10.10.10.254/24 -and- enable Proxy ARP on both 
(?) interfaces.  You will likely need to enter the target machine's IP 
addresses in a file that the Proxy ARP sub-system references to learn 
what target IPs that it needs to Proxy ARP for.


I might not have the nuances exactly correct because I've not done this 
in a long time.  But I have made this scenario work with the Proxy ARP 
support that currently exists in the Linux kernel.


So … I wonder what additional functionality your anyipd would provide. 
-  I'm actually quite curious to learn.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Grant Taylor

>> It is TCP/IPv4, so it's got compatible headers

> Are you referring to the 802.3 Ethernet (vs Ethernet II) frame type

No, I meant the IP and TCP headers. Those are end-end; the Ethernet stuff is
just a local wrapping, and can be substituted.

> I was not aware that there was code that supported /only/ Class A (/8)
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
> I /thought/ that everything was either classful (as in supports all 
> three classes: A, B, and C) or classless (as in supports CIDR).
> Is my networking history missing something else?

Yes. There was a stage before A/B/C. See RFC-760.

> Please clarify ... what you mean by ARPANET interface? Are you
> referring to host specific hardware that was used to communicate
> with an IMP?

Basically, yes.

The ARPANET supported several different kinds of interfaces between the IMPs
(the switching nodes in the ARPANET) and hosts, but the 'usual' one was
either 'Local Host' (LH) or 'Distant Host' (DH) which were _basically_
identical except at the very lowest level - LH was TTL, and DH was
differential pair.

Those interfaces were a custom bit-serial thing with a handshake (with
"there's-your-bit", "ready-for-next-bit" lines, etc); see BBN Report #1822:

  http://www.bitsavers.org/pdf/bbn/imp/BBN1822_Jan1976.pdf  

So the "ARPANET interface" in the host is a piece of custom hardware (some
were DMA; I also used one which was interrupt per byte) which went on the
host, which talked 1822 (as it was called), of either the DH or LH physical
form.

(There was also an Host/IMP interface called VDH, but that used a modem, and
a _lot_of software; see here:

  https://en.wikipedia.org/wiki/Talk:Network_Control_Program#Layer_locations

for a bit more about it.)


> Do the necessary emulators support the ARPANET interface?

Dunno, but they shouldn't be too hard to add.

The real problem is going to be 'what do you hook the simulated ARPANET
interfaces up to, and how'? I know they have IMP code running in simulators:

  http://mailman.trailing-edge.com/pipermail/simh/2013-November/007672.html

but I dunno how one would hook _that_ simulation up to a simulated host
running a simulated ARPANET interface.


Easier, to get this old TCP/IP running, might be to write a Unix V6 driver for
an Ethernet card (one the simulators do support - I know Ersatz-11 does the
Interlan NI1010A/2010A, which is nice and simple) and write an Ethernet
network interface module for that TCP, which talks to said driver; i.e. just
replace the ARPANET interface stuff completely.

Noel

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/18/2018 10:53 AM, Peter Coghlan via cctalk wrote:
I thought that what Novell refers to as "IEEE 802.3 raw" was an early day 
foulup on their part where they put IPX data directly into IEEE 802.3 
frames with nothing to indicate what protocol was being transported.


That's my understanding as well.

It's also my understanding that they made this decision prior to the 
standards we use today existed.  -  So, assuming my understanding is 
correct, I don't fault them for betting on the wrong option.


It became a problem because lots of people whose first experience of 
networking was a Novell Netware server used it because it was the default 
frame type, making life difficult for them when they wanted to add other 
protocols to their network later on.


Agreed.

The above are what they should have used instead of IEEE 802.3 "raw" 
if they really wanted to fly the 802.3 flag.


I don't know that Novell /wanted/ to fly the 802.3 flag.  I think they 
just wanted something that worked.  Purportedly, standards didn't exist 
yet, or weren't widely adopted, and they made a decision.  Granted, in 
retrospect it was the wrong decision.  But it did work for them at the time.


As far as I know, anyone who wanted everything to work just used Ethernet 
II (and 802.3 / 802.2 SNAP if they also wanted Appletalk support). 
I don't thing IEEE 802.3 with 802.2 and no SNAP was very useful because 
of the limited number of protocols it could be used to specify.


Agreed.

Though most of this is related to having multiple protocols on the same 
network segment / broadcast domain.  -  It's also my understanding that 
most businesses had multiple disconnected networks (likely using 
different physical technology) that had their native protocol(s) and 
didn't inter operate with each other.


Maybe, if V-delta-4 and before used IEEE 802.3 with 802.2 but I doubt 
if anyone other than Novell used what they called IEEE 802.3 "raw".


Fair enough.  I don't have any information to refute that.  -  So I 
modify my statement to be "I wonder if NetWare 4.x / 5.x can route IP 
between (what Novell called) 802.2 and Ethernet II.  ;-)


My desire is to find a way to interconnect between the existing 
protocols & frame types without needing to modify things on hosts.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Peter Coghlan via cctalk]

Here's a link with a lot of gory details on NetWare's support of 
multiple Ethernet frame types.


Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
  - https://support.novell.com/techcenter/articles/ana19930905.html

Here are the four frame types that NetWare supports:

  - Ethernet II
 - I think this is what we are using for just about everything today.
  - IEEE 802.3 "raw"
 - I'm speculating that this is the frame type that Frank is referring to 
above.


I thought that what Novell refers to as "IEEE 802.3 raw" was an early day
foulup on their part where they put IPX data directly into IEEE 802.3 frames
with nothing to indicate what protocol was being transported.  It became a
problem because lots of people whose first experience of networking was a
Novell Netware server used it because it was the default frame type, making
life difficult for them when they wanted to add other protocols to their
network later on.



 - IEEE 802.3 with 802.2
 - IEEE 802.3 with 802.2 SNAP



The above are what they should have used instead of IEEE 802.3 "raw" if they
really wanted to fly the 802.3 flag.  As far as I know, anyone who wanted
everything to work just used Ethernet II (and 802.3 / 802.2 SNAP if they also
wanted Appletalk support).  I don't thing IEEE 802.3 with 802.2 and no SNAP
was very useful because of the limited number of protocols it could be used
to specify.



I /think/ that NetWare can bind IP to all four Ethernet frame types. 
Hopefully one of them is compatible with V-delta-4 and before.




Maybe, if V-delta-4 and before used IEEE 802.3 with 802.2 but I doubt if
anyone other than Novell used what they called IEEE 802.3 "raw".

Regards,
Peter Coghlan.

Re: Reviving ARPAnet

[Paul Koning via cctalk]

> On Jan 18, 2018, at 12:27 PM, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
> ...
>> So you might think I'd be able to move files between it and a modern FreeBSD 
>> box, right?  I mean, it's all just Ethernet, right?
> 
> Ethernet != Ethernet
> 
> I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
> a router to convert from one Ethernet frame type to another Ethernet frame 
> type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.

I didn't know there's any such thing as IP over 802.3.  There's IP over 802.2 
(LLC) which is used for things like FDDI, but it would be weird to attempt that 
on Ethernet.

> ...
> Here are the four frame types that NetWare supports:
> 
> - Ethernet II
>- I think this is what we are using for just about everything today.
> - IEEE 802.3 "raw"
>- I'm speculating that this is the frame type that Frank is referring to 
> above.

That's the infamous non-compliant mess Netware came up with by not 
understanding the 802 standard.  It's never valid to run "raw 802.3" -- the 
only correct usage is 802.2 (LLC n for some n) over a MAC layer like 802.3 or 
FDDI.  SNAP is essentially an additional muxing layer on top of 802.2.

paul

IP address classes vs CIDR (was Re: Reviving ARPAnet)

[Eric Smith via cctalk]

On Thu, Jan 18, 2018 at 10:39 AM, Grant Taylor via cctalk <
cctalk@classiccmp.org> wrote:

> I was not aware that there was code that supported /only/ Class A (/8)
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
>
> I /thought/ that everything was either classful (as in supports all three
> classes: A, B, and C) or classless (as in supports CIDR).
>

Years ago I added a configurable "bozo-arp" feature to the Telebit
NetBlazer router, which would respond to ARP requests for non-local
addresses and reply with the router's MAC address (on that interface),
specifically in order to make classful-only hosts work on a CIDR network.
Later someone paid me to write a NetBSD daemon ("anyipd") to do the same
thing, though for an entirely different reason. Recently I've needed that
functionality on Linux, as I have multiple old systems that only understand
classful, including the AT UnixPC (7300 or 3B1). I suppose I should
rewrite and open-source it.

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/17/2018 11:33 AM, Noel Chiappa via cctalk wrote:
This just a guess, but 'sort of'? It is TCP/IPv4, so it's got compatible 
headers, but I don't know if other parts have changed enough to make it 
not work.


Are you referring to the 802.3 Ethernet (vs Ethernet II) frame type that 
Frank mentioned?


E.g. it probably only supports class A addresses, for instance, which 
is going to influence the code for picking the first-hop router.


I was not aware that there was code that supported /only/ Class A (/8) 
addresses and /not/ Class B (/16) or Class C (/24) addresses.


I /thought/ that everything was either classful (as in supports all 
three classes: A, B, and C) or classless (as in supports CIDR).


Is my networking history missing something else?

Also, do any of the systems that people want to emulate have conflicting 
classful networks?  -  Read:  Were any of the systems that people want 
to emulate on the same classful network?


If all the systems that people want to emulate are on different classful 
networks, it should be relatively trivial to interconnect them.



Also, the only driver is, IIRC, for an ARPANET interface.


Please clarify for this n00b what you mean by ARPANET interface?  Are 
you referring to host specific hardware that was used to communicate 
with an IMP?


Do the necessary emulators support the ARPANET interface?



--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Grant Taylor via cctalk]

On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
(V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is 
late enough for it to be able to do IP over Ethernet (vs. V-delta-4 and 
before which could only do IEEE over 802.3).  And it has an FTP client.


Please clarify what you mean by "IP over Ethernet", specifically what 
frame type?


Are you talking about Ethernet II frames?

So you might think I'd be able to move files between it and a modern 
FreeBSD box, right?  I mean, it's all just Ethernet, right?


Ethernet != Ethernet

I'm wondering if it might be possible to use an old NetWare 4.x / 5.x 
box as a router to convert from one Ethernet frame type to another 
Ethernet frame type.  I.e. from IP over Ethernet II frames to IP over 
802.3 frames.


I actually don't know if Linux can do this or not.  My typical go to 
tool might not help here.  :-/


Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") 
in V-delta-9 and before, such that it tears down the connection with 
a failure if a packet is received with IP type-of-service not zero. 
And the FreeBSD FTP server sets a socket option that gets FreeBSD to 
send that sort of packet.


At a previous employer, I went round with HP a bit on behalf of a mutual 
customer and got HP to issue a patch for NS Transport that corrects 
this behavior on the MPE side.  Clearly, I don't have that patch on 
this system.


I think we all have experiences like that.  Some sort of custom code 
that we didn't care about at the time (beyond fixing the problem) that 
we would now like to get our hands on years later.


FreeBSD is FreeBSD, and I can build its FTP server from source and 
change it so it works in this situation; but I think this should give 
y'all some idea of the hilarity that can ensue when you exhume a 1980s 
TCP/IP and put it on your network.


I wonder if there are other tricks that can be used to work around this 
without needing to recompile services.  I.e. use IPTables (or FreeBSD's 
counterpart that I don't know the name of) to change the type-of-service 
to something other than 0.


Here's a link with a lot of gory details on NetWare's support of 
multiple Ethernet frame types.


Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
 - https://support.novell.com/techcenter/articles/ana19930905.html

Here are the four frame types that NetWare supports:

 - Ethernet II
- I think this is what we are using for just about everything today.
 - IEEE 802.3 "raw"
- I'm speculating that this is the frame type that Frank is 
referring to above.

 - IEEE 802.3 with 802.2
 - IEEE 802.3 with 802.2 SNAP

I /think/ that NetWare can bind IP to all four Ethernet frame types. 
Hopefully one of them is compatible with V-delta-4 and before.


Obviously addressing would be a concern.  -  I want to do some more 
digging to see if NetWare supports any form of Proxy ARP.  Hopefully 
Proxy ARP support would allow us to form proto bridges to extend the 
classful /A or /B or /C networks that the desired nodes are in.


I'm happy to ponder some more scheming and networking black magic if 
people are interested.




--
Grant. . . .
unix || die

Re: Reviving ARPAnet

[Warner Losh via cctalk]

On Wed, Jan 17, 2018 at 1:12 PM, Frank McConnell via cctalk <
cctalk@classiccmp.org> wrote:

> > On Jan 17, 2018, at 10:18, Warner Losh via cctalk 
> wrote:
> >
> > On Wed, Jan 17, 2018 at 5:40 AM, Noel Chiappa via cctalk <
> > cctalk@classiccmp.org> wrote:
> >
> >>  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6
> >>
> >> (The latter includes NCP as well as TCP/IP.)
> >>
> >
> > I'm curious: does it inter-operate with modern TCP/IP implementations?
>
> This is a more serious question than one might think, but I know you
> (Warner) have been around long enough to have gone to Interop when it was
> about improving network interoperability.
>
> So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09
> (V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late
> enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before
> which could only do IEEE over 802.3).  And it has an FTP client.
>
> So you might think I'd be able to move files between it and a modern
> FreeBSD box, right?  I mean, it's all just Ethernet, right?
>
> Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport")
> in V-delta-9 and before, such that it tears down the connection with a
> failure if a packet is received with IP type-of-service not zero.  And the
> FreeBSD FTP server sets a socket option that gets FreeBSD to send that sort
> of packet.
>
> At a previous employer, I went round with HP a bit on behalf of a mutual
> customer and got HP to issue a patch for NS Transport that corrects this
> behavior on the MPE side.  Clearly, I don't have that patch on this system.
>
> FreeBSD is FreeBSD, and I can build its FTP server from source and change
> it so it works in this situation; but I think this should give y'all some
> idea of the hilarity that can ensue when you exhume a 1980s TCP/IP and put
> it on your network.
>

A pre-Interop TCP/IP at that :) It's kinda why I was asking...

Warner

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 17, 2018, at 10:18, Warner Losh via cctalk  
> wrote:
> 
> On Wed, Jan 17, 2018 at 5:40 AM, Noel Chiappa via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>>  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6
>> 
>> (The latter includes NCP as well as TCP/IP.)
>> 
> 
> I'm curious: does it inter-operate with modern TCP/IP implementations?

This is a more serious question than one might think, but I know you (Warner) 
have been around long enough to have gone to Interop when it was about 
improving network interoperability.

So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
(V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late 
enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before which 
could only do IEEE over 802.3).  And it has an FTP client.

So you might think I'd be able to move files between it and a modern FreeBSD 
box, right?  I mean, it's all just Ethernet, right?

Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") in 
V-delta-9 and before, such that it tears down the connection with a failure if 
a packet is received with IP type-of-service not zero.  And the FreeBSD FTP 
server sets a socket option that gets FreeBSD to send that sort of packet.

At a previous employer, I went round with HP a bit on behalf of a mutual 
customer and got HP to issue a patch for NS Transport that corrects this 
behavior on the MPE side.  Clearly, I don't have that patch on this system.

FreeBSD is FreeBSD, and I can build its FTP server from source and change it so 
it works in this situation; but I think this should give y'all some idea of the 
hilarity that can ensue when you exhume a 1980s TCP/IP and put it on your 
network.

-Frank McConnell

Re: Reviving ARPAnet

[Charles Anthony via cctalk]

On Wed, Jan 17, 2018 at 10:16 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Charles Anthony
>
> > it was shipped has an "unbundled" product.
>
> Ah. I assumed that what had happened was that the set of source files at
> MIT
> was just what was in the 'last release', and the NCP code had been
> discarded
> by then.
>
> I wonder if it's on a backup tape that MIT retained, somewhere?
>
> Possibly; we have been rattling doorknobs looking for old tapes.

>
> So now I'm curious - weren't many other pieces of important software
> similarly
> "unbundled", and if so, were those missing too?
>
>
Off of the top of my head:

TCP.

Source for the Pascal Compiler.

T microfiche explaining how to use ISOLTS and interpreting the
diagnostics.

There is a lurking bug in GTSS (the GCOS simulator) that is apparently
expressing itself in a GCOS library routine; I need to see the source for
that routine to make headway on diagnosis, but GCOS source was never
released, and is still tightly held, so that is probably never going to
happen.

-- Charles

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Warner Losh

> I'm curious: does it inter-operate with modern TCP/IP implementations?

This just a guess, but 'sort of'? It _is_ TCP/IPv4, so it's got compatible
headers, but I don't know if other parts have changed enough to make it not
work.

E.g. it probably only supports class A addresses, for instance, which is going
to influence the code for picking the first-hop router.

Also, the only driver is, IIRC, for an ARPANET interface.

  Noel

Re: Reviving ARPAnet

[Warner Losh via cctalk]

On Wed, Jan 17, 2018 at 5:40 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

>   http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6
>
> (The latter includes NCP as well as TCP/IP.)
>

I'm curious: does it inter-operate with modern TCP/IP implementations?

Warner

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Charles Anthony

> it was shipped has an "unbundled" product.

Ah. I assumed that what had happened was that the set of source files at MIT
was just what was in the 'last release', and the NCP code had been discarded
by then.

I wonder if it's on a backup tape that MIT retained, somewhere?


So now I'm curious - weren't many other pieces of important software similarly
"unbundled", and if so, were those missing too?

Noel

Re: Reviving ARPAnet

[Charles Anthony via cctalk]

On Wed, Jan 17, 2018 at 4:40 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Lars Brinkhoff
>
> > - Multics NCP has not been located.
>
> Really? It wasn't in the code dump at MIT?
>
>
Nope; it was shipped has an "unbundled" product.

-- Charles

Re: Reviving ARPAnet

[Lars Brinkhoff via cctalk]

Noel Chiappa wrote:
>> - Multics NCP has not been located.
> Really? It wasn't in the code dump at MIT?

I asked my Multics guy about it, and he said it was missing.  I don't
know about the code dump.

> I'm not sure a VMS machine was ever on the NCP ARPANet? So maybe they
> were front-ended somehow?

Yes, it could be.  I did look at some host tables.  Maybe it
was the AMES-11, but now I see it seems to have a PDP-11 frontend.

> There's a July '77 one at the end of this:
> and a January '79 copy of the MIT-SAIL one at the end here:

Thanks!

Re: Reviving ARPAnet

[william degnan via cctalk]

On Wed, Jan 17, 2018 at 7:50 AM, Noel Chiappa via cctalk <
cctalk@classiccmp.org> wrote:

> > From: Phil Budne
>
> > I asked around for v6 Unix with "NCP" code when the IMP code was
> > resurected, but never found it
>
> Yeah, that one was retrieved only recently, when Chuck managed to read an
> old
> dump tape I had of the MIT-CSR PWB1 Unix PDP-11. We didn't run NCP on that
> machine, but I had squirreled away that code (and the BBN code) on it (in
> case we ever had any use for it).
>
> Noel
>


I have the NIC card with fixed IP address from a late 70's U of Delaware's
QBUS or VAX (I believe), so I am ready to participate.  Please if you get
the chance send me a VAX 750/780 and a few cards and I am in.

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Phil Budne

> I asked around for v6 Unix with "NCP" code when the IMP code was
> resurected, but never found it

Yeah, that one was retrieved only recently, when Chuck managed to read an old
dump tape I had of the MIT-CSR PWB1 Unix PDP-11. We didn't run NCP on that
machine, but I had squirreled away that code (and the BBN code) on it (in
case we ever had any use for it).

Noel

Re: Reviving ARPAnet

[Noel Chiappa via cctalk]

> From: Lars Brinkhoff

> - Multics NCP has not been located.

Really? It wasn't in the code dump at MIT?

> - Unix?

For V6 NCP, we have several versions:

  http://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC
  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6

(The latter includes NCP as well as TCP/IP.)

> - VMS?

I'm not sure a VMS machine was ever on the NCP ARPANet? Hmm, looking at a
'Hosts' table from 3-Mar-82 (NCP was only turned off in January of '83), I
see two machines with "xxx-VMS"names, and directly connected to IMPs, _but_
no OS is given. So maybe they were front-ended somehow?


> Does anyone have any host tables between 1975 and 1981?

There's a July '77 one at the end of this:

  http://www.walden-family.com/dave/archive/bbn-tip-man.txt

and a January '79 copy of the MIT-SAIL one at the end here:

  https://tools.ietf.org/rfc/rfc752.txt

Starting around '82, they are more common: stick a phrase from the header of
the above into the "this exact word or phrase" box in Google's Advanced
Search, and you get things like this:

  http://pdp-10.trailing-edge.com/BB-H137D-BM/06/new-system/hstnam.txt.html
  https://trac.common-lisp.net/mit-cadr/export/274/trunk/lisp/chaos/hosts.text

Noel

Re: Reviving ARPAnet

[Phil Budne via cctalk]

> - Unix?

I asked around for v6 Unix with "NCP" code when the IMP code was
resurected, but never found it

Reviving ARPAnet

[Lars Brinkhoff via cctalk]

Hello,

What software, hardware, simulators, emulators, etc are there that could
run ARPAnet today?

- ITS has support for NCP, but I don't know if it works.
- There's source code for the IMP.
- TENEX seems ok at a quick glance.
- WAITS, likewise.
- Multics NCP has not been located.
- Unix?
- IBM mainframes?
- NOS?
- VMS?

Does anyone have any host tables between 1975 and 1981?

Classic regards,
Lars Brinkhoff