6 Apr
2021
6 Apr
'21
10:23 p.m.
MIM::DECNET.TXT states that area 63 is "Reserved for hidden area testing". Is
area 63 routing suppressed by PyDECnet and/or any other methods of connecting to HECnet?
If one were to play around with local nodes in area 63 without remembering to bring down
the upstream HECnet connection, what would happen?
I am interested in creating some useful semi-turnkey SIMH VAX instances to share with
friends who are interested in playing with VAXen and/or connecting to HECnet, but are
hesitant because of the learning curve involved. I figured it might be desirable to set up
the simulations to use nodes in area 63 by default. I'll naturally want to test out
intercommunication with my other simulations and real VAXen, and I'd like to
understand whether I need to shut down my PyDECnet connection to HECnet while I am doing
that.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
6 Apr
6 Apr
10:43 p.m.
On Apr 6, 2021, at 4:23 PM, Mark J. Blair <nf6x at
nf6x.net> wrote:
MIM::DECNET.TXT states that area 63 is "Reserved for hidden area testing". Is
area 63 routing suppressed by PyDECnet and/or any other methods of connecting to HECnet?
If one were to play around with local nodes in area 63 without remembering to bring down
the upstream HECnet connection, what would happen?
There's nothing special about area number 63 in the architecture, or in PyDECnet --
nor, as far as I know, in any other DECnet implementation.
The "hidden area" idea was used within DEC, since the Engineering Net at some
point outgrew the 16 bit address space. I don't really remember anymore how it was
used. I can try to construct some schemes that would work; the one I just constructed in
my head is rather messy and I don't know if it is correct. A possible answer relies
on using max areas = 62 in most of the network, but = 63 in the routers that connect to
hidden area entry points.
The other complication is that we'd have to resurrect the PMR / PASSTHRU object.
There's a PDP-10 version that's been posted, but my Macro-10 is much too feeble
these days to read it. I don't have the RSTS version, but I may have code that talks
to it which may be sufficient. Given a decent spec of how it works, a Python version
would be easy.
paul
11:21 p.m.
Thanks, that is interesting and good to know. Ok, I should probably just use node numbers
in my own amply sized allocation within area 2. I'll think of some node names to
request for them. If a collision occurs later because of 2 people running unchanged
simulation instances on subnets with live HECnet connections, that should limit the damage
to just those individuals and anybody trying to connect to them, right?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
11:40 p.m.
Paul,
That?s exactly how it was used at DEC and how I have been using it here.
-Steve Davidson
SF:iP1
On Apr 6, 2021, at 17:22, Mark J. Blair <nf6x at
nf6x.net> wrote:
?Thanks, that is interesting and good to know. Ok, I should probably just use node
numbers in my own amply sized allocation within area 2. I'll think of some node names
to request for them. If a collision occurs later because of 2 people running unchanged
simulation instances on subnets with live HECnet connections, that should limit the damage
to just those individuals and anybody trying to connect to them, right?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
7 Apr
7 Apr
1:51 a.m.
On Apr 6, 2021, at 5:21 PM, Mark J. Blair <nf6x at
nf6x.net> wrote:
Thanks, that is interesting and good to know. Ok, I should probably just use node numbers
in my own amply sized allocation within area 2. I'll think of some node names to
request for them. If a collision occurs later because of 2 people running unchanged
simulation instances on subnets with live HECnet connections, that should limit the damage
to just those individuals and anybody trying to connect to them, right?
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
If I understand right...
Given that you have an area number assigned to you, if people connect nodes in that area
and get node number conflicts, that won't bother anyone outside the area unless they
try to connect to that address. If they do, they'll probably reach one of those two
and the connection may work, while the other is essentially invisible. Or if you're
unlucky, the packets will be spread to the two and no connection to that address works.
But other nodes in the area will be ok.
The main thing is to connect nodes you're not sure about via an L1 router, NOT an L2
(area) router. That way, if they misbehave, it can't spread over the L2 backbone.
paul
2:21 a.m.
On Apr 6, 2021, at 4:51 PM, Paul Koning <paulkoning
at comcast.net> wrote:
Given that you have an area number assigned to you
I don't have a whole area number. I have a 100-number chunk of Robert's area
reserved for me.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
2:50 a.m.
On Apr 6, 2021, at 8:21 PM, Mark J. Blair <nf6x at
nf6x.net> wrote:
Ok. The same principle holds: a misbehaving node connected to an L1 router can mess up at
most that area. If it mistakenly grabs someone else's node number, those two nodes
are affected but others are not. The only way it could do worse things is if it's a
router and it claims to be a really good path to other nodes in the area, and then
doesn't live up to the promise. (That happened in the Internet once, when routers in
some corner of the Internet, Hong Kong perhaps, claimed to be the best way to reach
Pakistan.)
Short of major software malfunction, not likely when dealing with VMS systems, the main
worry is misconfiguration. For that, connect via an L1 router and look for node address
errors.
paul
On Apr 6, 2021, at 4:51 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Given that you have an area number assigned to you
I don't have a whole area number. I have a 100-number chunk of Robert's area
reserved for me.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/ 
3:17 a.m.
Hi, all.
First of all, to comment on the OP. Area 63 has indeed been reserved for
people interested in doing hidden areas, like DEC did. I also do not
remember much detail right now, but others asked for it, and I saw no
problem in reserving one area for it. Others might even be using this,
based on comments here.
When it comes to PMR and PASSTHRU, I might have some stuff for RSX that
could answer some questions, but I would have to dig through things...
Not sure if there is enough interest for any digging around right now.
Finally, when it comes to duplicate addresses, the most obvious
casualties are always the two nodes where the duplication actually
happens. If they are just endnodes, the damage always stops there. While
this is maybe not a good state, it at least is containable. But make
sure people do not get creative and just start changing to arbitrary
other addresses, or we are going to need to take more drastic action.
I can understand the desire to make it easier for people with little
understanding to hook up, there is a risk that if you don't know what
you are doing, you create problems for others that you don't even
understand. I would really recommend that we don't make it *too* easy
for people to hook up. I don't want to hold hands for people who have no
idea what they are doing, just to prevent chaos on HECnet.
Finally, if you setup nodes that are not endnodes, the responsibilities
grow. Especially if you are in an area where others are also active,
since any kind of router can potentially wreck havoc in an area, or
possible even with the inter-area routing.
So for those, I would even more suggest that you do not set anything
like that up for someone who don't know what they are doing.
Now, these comments are not really targeted at anyone in particular, but
something for everyone to be aware of, and consider, when you hook up
others. HECnet is rather distributed, really. I do manage the area
allocation, and area 1. But when I hand out an area to someone, then
everything about that area becomes that persons responsibility. So
adding new people, new nodes, new links, or whatever, is totally up to
them. I can certainly offer a bit of support, but the "owner" of an area
is really the deciding person on what happens in that area. If the owner
sub-let part of the area to someone else, I think it still makes sense
to consult with that area owner, if you further sub-let, or hook others
up, since this definitely can have an impact on the area.
Think about it. We should all try to be good neighbors. DECnet, while
ok, isn't at the robustness level, or security (well there are none) of
modern internets.
Johnny
On 2021-04-07 02:50, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Apr 6, 2021, at 8:21 PM, Mark J. Blair
<nf6x at nf6x.net> wrote:
Ok. The same principle holds: a misbehaving node connected to an L1 router can mess up
at most that area. If it mistakenly grabs someone else's node number, those two nodes
are affected but others are not. The only way it could do worse things is if it's a
router and it claims to be a really good path to other nodes in the area, and then
doesn't live up to the promise. (That happened in the Internet once, when routers in
some corner of the Internet, Hong Kong perhaps, claimed to be the best way to reach
Pakistan.)
Short of major software malfunction, not likely when dealing with VMS systems, the main
worry is misconfiguration. For that, connect via an L1 router and look for node address
errors.
paul
On Apr 6, 2021, at 4:51 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Given that you have an area number assigned to you
I don't have a whole area number. I have a 100-number chunk of Robert's area
reserved for me.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/ 
3:24 a.m.
So for the academic networks in the past when DECnet was supported on a
world-wide basis, called "HEPnet" and run by the high_energy_physics
people and DOE we used the max-area and PMR. There where PMR objects on
VMS to.
So all of the DECnet nodes in the Nordics where in areas higher than
(if I remember right) 42.
So 43-63 was used locally, and the global nodes where in lower area
numbers and if you wanted to talk from something in "the big world"
you used the PMR object of a node in the "low region"
For example, the VAX at Fysicum in Uppsala was such a node in area 22..
-P
7:21 p.m.
On Apr 6, 2021, at 9:17 PM, Johnny Billquist <bqt
at softjar.se> wrote:
Hi, all.
First of all, to comment on the OP. Area 63 has indeed been reserved for people
interested in doing hidden areas, like DEC did. I also do not remember much detail right
now, but others asked for it, and I saw no problem in reserving one area for it. Others
might even be using this, based on comments here.
When it comes to PMR and PASSTHRU, I might have some stuff for RSX that could answer some
questions, but I would have to dig through things... Not sure if there is enough interest
for any digging around right now.
If you find anything I would be interested in adding support to Linux DECnet.
Finally, when it comes to duplicate addresses, the
most obvious casualties are always the two nodes where the duplication actually happens.
If they are just endnodes, the damage always stops there. While this is maybe not a good
state, it at least is containable. But make sure people do not get creative and just start
changing to arbitrary other addresses, or we are going to need to take more drastic
action.
I can understand the desire to make it easier for people with little understanding to
hook up, there is a risk that if you don't know what you are doing, you create
problems for others that you don't even understand. I would really recommend that we
don't make it *too* easy for people to hook up. I don't want to hold hands for
people who have no idea what they are doing, just to prevent chaos on HECnet.
Finally, if you setup nodes that are not endnodes, the responsibilities grow. Especially
if you are in an area where others are also active, since any kind of router can
potentially wreck havoc in an area, or possible even with the inter-area routing.
So for those, I would even more suggest that you do not set anything like that up for
someone who don't know what they are doing.
Now, these comments are not really targeted at anyone in particular, but something for
everyone to be aware of, and consider, when you hook up others. HECnet is rather
distributed, really. I do manage the area allocation, and area 1. But when I hand out an
area to someone, then everything about that area becomes that persons responsibility. So
adding new people, new nodes, new links, or whatever, is totally up to them. I can
certainly offer a bit of support, but the "owner" of an area is really the
deciding person on what happens in that area. If the owner sub-let part of the area to
someone else, I think it still makes sense to consult with that area owner, if you further
sub-let, or hook others up, since this definitely can have an impact on the area.
Think about it. We should all try to be good neighbors. DECnet, while ok, isn't at
the robustness level, or security (well there are none) of modern internets.
In the late ?80s I was a member of the Distributed Services group working on DAAS
(Distributed Authentication and Authorization Service). The group was also responsible for
distributed naming services (DNADNS), distributed file service (DFS) and distributed time
service (DTSS). We licensed the RSA algorithm for prototyping and we were working on an
architecture using distributed CAs similar to what is used today. I had a version of CTERM
on Ultrix (dlogin) which used a crypto exchange to perform an immediate login without
entering a password. The main problem was the lack of compute power. A Microvax II, using
hand crafted assembler, could manage a blistering 8KB/s of DES encrypt or decrypt and the
RSA code was many times slower. I moved over to the Network Advanced Development group in
1990 and, I think, the assigned architect left the company around the same time so nothing
further came of the work.
John.
Johnny
On 2021-04-07 02:50, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Apr 6,
2021, at 8:21 PM, Mark J. Blair <nf6x at nf6x.net> wrote:
Ok. The same principle holds: a misbehaving node connected
to an L1 router can mess up at most that area. If it mistakenly grabs someone else's
node number, those two nodes are affected but others are not. The only way it could do
worse things is if it's a router and it claims to be a really good path to other nodes
in the area, and then doesn't live up to the promise. (That happened in the Internet
once, when routers in some corner of the Internet, Hong Kong perhaps, claimed to be the
best way to reach Pakistan.)
Short of major software malfunction, not likely when dealing with VMS systems, the main
worry is misconfiguration. For that, connect via an L1 router and look for node address
errors.
paul On Apr 6, 2021, at 4:51 PM, Paul Koning
<paulkoning at comcast.net> wrote:
Given that you have an area number assigned to you
I don't have a whole area number. I have a 100-number chunk of Robert's area
reserved for me.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
https://www.nf6x.net/
1117
days inactive
1118
days old
9 comments
6 participants
participants (6)
-
bqt＠softjar.se -
john＠forecast.name -
nf6x＠nf6x.net -
paulkoning＠comcast.net -
roll＠stupi.com -
steve＠davidson.net