Johnny wrote:
That is not really a big issue. DECnet do not have a requirement for a
coherent nodename database. Every machine can have its own.
This is technically true, but it's really not very useful to have a
network with duplicate node names. After all, if I post a message saying
"phone me on ABC::" or "copy these files from XYZ::" and half the users have
a different ABC or XYZ, then people are not going to be happy.
Sure, it may be that the Italian guys never access our nodes and vice
versa, but if that's true then what's the point in integrating?
Bob
P.S. Does anybody have a list of the nodes on the Italian network?
Yes, it's called DTR
------Origineel bericht------
Van: Fred
Afzender: owner-hecnet at Update.UU.SE
Aan: hecnet at Update.UU.SE
Beantwoorden: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
Verzonden: 26 november 2011 13:51
On Sat, 26 Nov 2011, Johnny Billquist wrote:
Anyone else could do the same trick, using the remote datatrieve interface to
access the nodename database on MIM, and setting up the local nodename
database. That would also allow you to pick just certain areas, or whatnot...
Speaking of Datatrieve - is there a hobbyist license for this?
Fred
On Sat, 26 Nov 2011, Johnny Billquist wrote:
Anyone else could do the same trick, using the remote datatrieve interface to access the nodename database on MIM, and setting up the local nodename database. That would also allow you to pick just certain areas, or whatnot...
Speaking of Datatrieve - is there a hobbyist license for this?
Fred
On 2011-11-26 13.19, H Vlems wrote:
I wasn't aware that moving to TCP would result in all that. UDP and TCP both
use the same IP addressing functionality. Only UDP is connectionless, i.e.
doesn't use acknowledgement messages and is thus a little faster than TCP
but less reliable. An IP address change is as much as a problem for UDP as
it is for TCP, I'd say.
Yes. IP address change is as much a "problem" for UDP as TCP. But at the same time not. :-)
In TCP, if the other end changes the IP address, the TCP connection will be reset, and your program will get an error returned. Thus you notice this. In UDP, you will continue to transmit as if nothing happened. In fact, nothing have changed from the UDP point of view. Packets are still sent to that same address. Only, there might now be some other machine receiving them than before. What that machine does is not something you have any control over (of course, a clever prgorammer can make the same happen for TCP, but it requires a lot of work, while in UDP it is the only behavior).
There is much more difference between TCP and UDP than the connection/connectionless issue. Of course, you could argue that everything else follows, but not neccesarily.
TCP do not have the concept of "packets". It's all a stream of bytes. As such, there is no guarantee that because you wrote 1500 bytes in one write, the receiver will receive 1500 bytes in one read. The receiver could just as well get three reads of 500 bytes each.
Also, TCP guarantees that data arrive in the same order it was sent. Thus, if the underlying layer loses a packet, TCP will buffer and resend data in order to keep its guarantee. So later data will be buffered, and not delivered, even if it have arrived, until older data have been delivered.
Also, in order to make sure the network is used optimally, TCP can keep from sending data, in order to make packets more "full". This is called the Nagle algorithm, and it can be disabled, but you are still not guaranteed that buffering will not happen somewhere between source and destination, or that TCP won't introduce delays.
And then you have various congestion control algorithms, slow start, and what not.
And of course, at connection time, you have the handshaking that must happen before the connection can be used.
UDP on the other hand guarantees nothing. Packets might be lost, duplicated, delivered out of order, and whatnot. In fact, pretty much (for the most part) just the same as ethernet. And packets are written whole, or not at all, and read the same. One write is delivered in one read. UDP have *packets*, not a stream of bytes.
Security is another issue. As you wrote, authentication is sent as clear
text so is not secure. Then again, it may only be used if there is a
connection to HECnet and that would make no difference anyhow.
With the current scheme in HECnet, packets are not accepted from unknown hosts (IP addresses), so random people cannot inject ethernet packets through the bridge to your local ethernet. Also, your local ethernet packets are not sent to any random host, but only hosts you have listed the address for in the bridge program.
It is way less than secure, but it do avoid the most glaring problems.
Encryption is fine, but it is an up hill struggle: it requires continuous
attention to keep up with technology. I doubt if HECnet is worth that
struggle.
Yeah. I don't think it is. :-)
And sorry for the long ramble about network technologies. :-)
Johnny
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 12:59
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 12.48, Johnny Billquist wrote:
On 2011-11-26 12.05, H Vlems wrote:
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.
To expand, perhaps, a little here.
If we switched to TCP, any change in IP addresses would be detected
"immediately", since the TCP connection would be lost at an IP change.
At that point, the bridge would need to re-resolve the address, and try
to establish a connection again. That would have to be repeated
regularly until a connection comes up. Since this is very blocking, we'd
have to change the bridge to be threaded, so that you have one thread
per connection. And then queue packets inside the bridge, with throwing
away when queues become to large, in order to prevent other connections
from becoming affected.
In addition, this would affect the complexity of things like config
reloads. Everything is, as usual, doable, but the work involved is not
trivial. And then, of course, we have all the certificate issues, and
all the code to deal with them.
And then, also, TCP can introduce unwanted network delays and
burstiness. It really don't fit well with what the bridge do. It
provides services not really needed.
And I really like simple solutions... :-)
Johnny
On 2011-11-26 13.13, H Vlems wrote:
You may be right about MIM being used as the "master" of the HECnet nodes,
even though DECnet phase IV has no such thing.
Right. It's purely a voluntary convention.
Actually I didn't use MIM
because I notcied it ran RSX-11, not an o/s I'm familiar with. So I looked
at the node databases of the area routers and just included them.
You do know that the OS of the host is pretty irrelevant for DECnet? You can run NCP on your local machine and query any other machine, using the same commands, no matter what the other machine is running.
NCP TELL MIM SHOW KNOWN NODES
works just as well on RSX, RSTS/E, VMS, TOPS-20, Windows, or (I assume) Ultrix.
Exactly how you copy the nodename database from MIM to your machine is a question for your local machine, and does not much involve MIM.
For VMS, COPY KNOWN NODES does the trick. If you run RSX, there is a program called NNC, which do the work.
The copy known nodes NCP command is powerful, it also allows you to mess up
a node database pretty fast!
Indeed. So you might want to think twice, or else you can start by just copying the nodenames to the volatile database. If things get screwed up, you can just restart and it will be reverted. (I'm talking VMS here, for other OSes, the colutions, problems, and workarounds differ.)
With a little programming, the information in Datatrieve may be converted to
commands that may be run by NCP. A text file filled with commands like:
DEFINE NODE 63.3 NAME TEST3
The last command would then be set known nodes all (IIRC). Of course you
could remove all unwanted entries first.
Yes.
In fact, the makefile I have on MIM to convert the Datatrieve database to nodenames looks like this:
FIX.CMD: HECNET.IDX
DTR @
READY HECNET
FIND HECNET WITH NAME NOT EQ "$(SYSNAM)"
FOR CURRENT PRINT "def nod " | NODE_ADDRESS | " name " | NODE_NAME -
ON FIX.CMD
^Z
sub /nonotify=FIX
and FIX.BAT is essentually just running NCP, and using FIX.CMD as the input. Of course a few things are in the details, but you get the idea, I would think...
Anyone else could do the same trick, using the remote datatrieve interface to access the nodename database on MIM, and setting up the local nodename database. That would also allow you to pick just certain areas, or whatnot...
Johnny
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 12:48
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 12.05, H Vlems wrote:
I agree with Johnny. The technical problems that are DECnet related, like
duplicate areas and duplicate nodenames are easily solved.
Possibly a lot of work, e.g. I had to move all my machines to another area
and it takes less than 5 minutes per system. Mandatory reboot included.
Incidentally, I documented the required procedures for several operating
systems (VMS, linux and Windows) and when appropriate for both phase IV
and
phase V.
So a couple of simple agreements is all that is necessary to merge the two
networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.
Right. The biggest concern would perhaps be that MIM is used as (I
think) the most central repository of HECnet related information, and as
such, it might be a bit unfortunate to move around. But apart from that,
any area is as good as any other area. Moving means some work, but it is
not complicated.
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Well that, or else continue with the "voluntary" system we have in place
now. Which is that I keep a database on MIM, to which all can send in
registrations, and anyone can cope the nodename database from MIM to
their own machine to get the same view as MIM have.
The actual database I have on MIM is stored in Datatrieve, with some
additional information, and then the DECnet nodename database is created
from that Datatrieve source.
Which is my way of saying that I'm not too fond of this "enhancement"...
:-)
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 11:36
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 08.43, Angela Kahealani wrote:
On Sat, Nov 26, 2011 at 02:35:17AM -0500, Steve Davidson wrote:
Well here's three reasons:
1) they use DECnet area 1 thus area collision
Yes. That was an unfortunate decision of them.
2) they use some of the names we already use thus name space collision
That is not really a big issue. DECnet do not have a requirement for a
coherent nodename database. Every machine can have its own. I keep a
nodename database on MIM, which people are welcome to register in, for
us to be able to copy and keep a synched version, but anyone on HECnet
can really have their own different database if they want to.
3) and from what I remember, they are entirely dynamic DNS based and
thus had to make major changes to the bridge to even exist.
The changes they made work just fine, BTW...
Yes. That was one reason that I remember, now that you mention it.
-Steve
So, then do they not have a superior solution which could be adopted by
the existing HECNET?
Depends on your definition of "superior". They manage dynamic addresses,
at the cost of either exposing to name resolution hiccups, slowness,
name poisoning, and whatnot, or else a potential for security exposure
if they send, and accept traffic from random nodes in some time window.
The latter reasons are why I do not have such a thing in the bridge in
general. DECnet is not a very secure protocol. Passwords fly through it
in clear text. I am not fond of the possibility of that traffic going to
some random address in general, and even less fond of opening up the
virtual ethernet to any random place to inject traffic.
I'm happy to discuss and explain the problems if people want to, but I
seriously doubt I'll change my mind. I have given it much thought over
the years.
Johnny
I wasn't aware that moving to TCP would result in all that. UDP and TCP both
use the same IP addressing functionality. Only UDP is connectionless, i.e.
doesn't use acknowledgement messages and is thus a little faster than TCP
but less reliable. An IP address change is as much as a problem for UDP as
it is for TCP, I'd say.
Security is another issue. As you wrote, authentication is sent as clear
text so is not secure. Then again, it may only be used if there is a
connection to HECnet and that would make no difference anyhow.
Encryption is fine, but it is an up hill struggle: it requires continuous
attention to keep up with technology. I doubt if HECnet is worth that
struggle.
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 12:59
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 12.48, Johnny Billquist wrote:
On 2011-11-26 12.05, H Vlems wrote:
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.
To expand, perhaps, a little here.
If we switched to TCP, any change in IP addresses would be detected
"immediately", since the TCP connection would be lost at an IP change.
At that point, the bridge would need to re-resolve the address, and try
to establish a connection again. That would have to be repeated
regularly until a connection comes up. Since this is very blocking, we'd
have to change the bridge to be threaded, so that you have one thread
per connection. And then queue packets inside the bridge, with throwing
away when queues become to large, in order to prevent other connections
from becoming affected.
In addition, this would affect the complexity of things like config
reloads. Everything is, as usual, doable, but the work involved is not
trivial. And then, of course, we have all the certificate issues, and
all the code to deal with them.
And then, also, TCP can introduce unwanted network delays and
burstiness. It really don't fit well with what the bridge do. It
provides services not really needed.
And I really like simple solutions... :-)
Johnny
You may be right about MIM being used as the "master" of the HECnet nodes,
even though DECnet phase IV has no such thing. Actually I didn't use MIM
because I notcied it ran RSX-11, not an o/s I'm familiar with. So I looked
at the node databases of the area routers and just included them.
The copy known nodes NCP command is powerful, it also allows you to mess up
a node database pretty fast!
With a little programming, the information in Datatrieve may be converted to
commands that may be run by NCP. A text file filled with commands like:
DEFINE NODE 63.3 NAME TEST3
The last command would then be set known nodes all (IIRC). Of course you
could remove all unwanted entries first.
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 12:48
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 12.05, H Vlems wrote:
I agree with Johnny. The technical problems that are DECnet related, like
duplicate areas and duplicate nodenames are easily solved.
Possibly a lot of work, e.g. I had to move all my machines to another area
and it takes less than 5 minutes per system. Mandatory reboot included.
Incidentally, I documented the required procedures for several operating
systems (VMS, linux and Windows) and when appropriate for both phase IV
and
phase V.
So a couple of simple agreements is all that is necessary to merge the two
networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.
Right. The biggest concern would perhaps be that MIM is used as (I
think) the most central repository of HECnet related information, and as
such, it might be a bit unfortunate to move around. But apart from that,
any area is as good as any other area. Moving means some work, but it is
not complicated.
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Well that, or else continue with the "voluntary" system we have in place
now. Which is that I keep a database on MIM, to which all can send in
registrations, and anyone can cope the nodename database from MIM to
their own machine to get the same view as MIM have.
The actual database I have on MIM is stored in Datatrieve, with some
additional information, and then the DECnet nodename database is created
from that Datatrieve source.
Which is my way of saying that I'm not too fond of this "enhancement"...
:-)
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 11:36
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 08.43, Angela Kahealani wrote:
On Sat, Nov 26, 2011 at 02:35:17AM -0500, Steve Davidson wrote:
Well here's three reasons:
1) they use DECnet area 1 thus area collision
Yes. That was an unfortunate decision of them.
2) they use some of the names we already use thus name space collision
That is not really a big issue. DECnet do not have a requirement for a
coherent nodename database. Every machine can have its own. I keep a
nodename database on MIM, which people are welcome to register in, for
us to be able to copy and keep a synched version, but anyone on HECnet
can really have their own different database if they want to.
3) and from what I remember, they are entirely dynamic DNS based and
thus had to make major changes to the bridge to even exist.
The changes they made work just fine, BTW...
Yes. That was one reason that I remember, now that you mention it.
-Steve
So, then do they not have a superior solution which could be adopted by
the existing HECNET?
Depends on your definition of "superior". They manage dynamic addresses,
at the cost of either exposing to name resolution hiccups, slowness,
name poisoning, and whatnot, or else a potential for security exposure
if they send, and accept traffic from random nodes in some time window.
The latter reasons are why I do not have such a thing in the bridge in
general. DECnet is not a very secure protocol. Passwords fly through it
in clear text. I am not fond of the possibility of that traffic going to
some random address in general, and even less fond of opening up the
virtual ethernet to any random place to inject traffic.
I'm happy to discuss and explain the problems if people want to, but I
seriously doubt I'll change my mind. I have given it much thought over
the years.
Johnny
On 2011-11-26 12.48, Johnny Billquist wrote:
On 2011-11-26 12.05, H Vlems wrote:
What I've read about the "enhancements" to the bridge program is yet
another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes,
you could change from UDP to TCP, include SSL, and certificates, to make
sure we keep it safe. But that would incur quite some costs both from an
administrative point of view, as well as lots more CPU resources to run
the bridge, and also more problems in porting it to other systems.
To expand, perhaps, a little here.
If we switched to TCP, any change in IP addresses would be detected "immediately", since the TCP connection would be lost at an IP change.
At that point, the bridge would need to re-resolve the address, and try to establish a connection again. That would have to be repeated regularly until a connection comes up. Since this is very blocking, we'd have to change the bridge to be threaded, so that you have one thread per connection. And then queue packets inside the bridge, with throwing away when queues become to large, in order to prevent other connections from becoming affected.
In addition, this would affect the complexity of things like config reloads. Everything is, as usual, doable, but the work involved is not trivial. And then, of course, we have all the certificate issues, and all the code to deal with them.
And then, also, TCP can introduce unwanted network delays and burstiness. It really don't fit well with what the bridge do. It provides services not really needed.
And I really like simple solutions... :-)
Johnny
On 2011-11-26 12.05, H Vlems wrote:
I agree with Johnny. The technical problems that are DECnet related, like
duplicate areas and duplicate nodenames are easily solved.
Possibly a lot of work, e.g. I had to move all my machines to another area
and it takes less than 5 minutes per system. Mandatory reboot included.
Incidentally, I documented the required procedures for several operating
systems (VMS, linux and Windows) and when appropriate for both phase IV and
phase V.
So a couple of simple agreements is all that is necessary to merge the two
networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.
Right. The biggest concern would perhaps be that MIM is used as (I think) the most central repository of HECnet related information, and as such, it might be a bit unfortunate to move around. But apart from that, any area is as good as any other area. Moving means some work, but it is not complicated.
What I've read about the "enhancements" to the bridge program is yet another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
I also wanted to keep the complexity and overhead down. Otherwise, yes, you could change from UDP to TCP, include SSL, and certificates, to make sure we keep it safe. But that would incur quite some costs both from an administrative point of view, as well as lots more CPU resources to run the bridge, and also more problems in porting it to other systems.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Well that, or else continue with the "voluntary" system we have in place now. Which is that I keep a database on MIM, to which all can send in registrations, and anyone can cope the nodename database from MIM to their own machine to get the same view as MIM have.
The actual database I have on MIM is stored in Datatrieve, with some additional information, and then the DECnet nodename database is created from that Datatrieve source.
Which is my way of saying that I'm not too fond of this "enhancement"...
:-)
Johnny
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 11:36
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 08.43, Angela Kahealani wrote:
On Sat, Nov 26, 2011 at 02:35:17AM -0500, Steve Davidson wrote:
Well here's three reasons:
1) they use DECnet area 1 thus area collision
Yes. That was an unfortunate decision of them.
2) they use some of the names we already use thus name space collision
That is not really a big issue. DECnet do not have a requirement for a
coherent nodename database. Every machine can have its own. I keep a
nodename database on MIM, which people are welcome to register in, for
us to be able to copy and keep a synched version, but anyone on HECnet
can really have their own different database if they want to.
3) and from what I remember, they are entirely dynamic DNS based and
thus had to make major changes to the bridge to even exist.
The changes they made work just fine, BTW...
Yes. That was one reason that I remember, now that you mention it.
-Steve
So, then do they not have a superior solution which could be adopted by
the existing HECNET?
Depends on your definition of "superior". They manage dynamic addresses,
at the cost of either exposing to name resolution hiccups, slowness,
name poisoning, and whatnot, or else a potential for security exposure
if they send, and accept traffic from random nodes in some time window.
The latter reasons are why I do not have such a thing in the bridge in
general. DECnet is not a very secure protocol. Passwords fly through it
in clear text. I am not fond of the possibility of that traffic going to
some random address in general, and even less fond of opening up the
virtual ethernet to any random place to inject traffic.
I'm happy to discuss and explain the problems if people want to, but I
seriously doubt I'll change my mind. I have given it much thought over
the years.
Johnny
I agree with Johnny. The technical problems that are DECnet related, like
duplicate areas and duplicate nodenames are easily solved.
Possibly a lot of work, e.g. I had to move all my machines to another area
and it takes less than 5 minutes per system. Mandatory reboot included.
Incidentally, I documented the required procedures for several operating
systems (VMS, linux and Windows) and when appropriate for both phase IV and
phase V.
So a couple of simple agreements is all that is necessary to merge the two
networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.
What I've read about the "enhancements" to the bridge program is yet another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Which is my way of saying that I'm not too fond of this "enhancement"...
Hans
-----Oorspronkelijk bericht-----
Van: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] Namens
Johnny Billquist
Verzonden: zaterdag, november 2011 11:36
Aan: hecnet at Update.UU.SE
Onderwerp: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 08.43, Angela Kahealani wrote:
On Sat, Nov 26, 2011 at 02:35:17AM -0500, Steve Davidson wrote:
Well here's three reasons:
1) they use DECnet area 1 thus area collision
Yes. That was an unfortunate decision of them.
2) they use some of the names we already use thus name space collision
That is not really a big issue. DECnet do not have a requirement for a
coherent nodename database. Every machine can have its own. I keep a
nodename database on MIM, which people are welcome to register in, for
us to be able to copy and keep a synched version, but anyone on HECnet
can really have their own different database if they want to.
3) and from what I remember, they are entirely dynamic DNS based and
thus had to make major changes to the bridge to even exist.
The changes they made work just fine, BTW...
Yes. That was one reason that I remember, now that you mention it.
-Steve
So, then do they not have a superior solution which could be adopted by
the existing HECNET?
Depends on your definition of "superior". They manage dynamic addresses,
at the cost of either exposing to name resolution hiccups, slowness,
name poisoning, and whatnot, or else a potential for security exposure
if they send, and accept traffic from random nodes in some time window.
The latter reasons are why I do not have such a thing in the bridge in
general. DECnet is not a very secure protocol. Passwords fly through it
in clear text. I am not fond of the possibility of that traffic going to
some random address in general, and even less fond of opening up the
virtual ethernet to any random place to inject traffic.
I'm happy to discuss and explain the problems if people want to, but I
seriously doubt I'll change my mind. I have given it much thought over
the years.
Johnny
