mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-23 01:48:06 +11:00
67 lines
2.8 KiB
Groff
67 lines
2.8 KiB
Groff
Copper Protocol :: Hierarchial Gateways
|
|
20kdc, 2017
|
|
|
|
"Hierarchial Gateways" are a system for ISP-like bodies to prevent their
|
|
users from causing havoc.
|
|
Note that this is not the only possible system, and implementors can do as they wish regarding addressing.
|
|
(However, for this reason, applications should allow specification of a prefix to all "internet"-level addresses.)
|
|
|
|
They are simply base low-level Copper nodes with two interfaces and the
|
|
following rules:
|
|
|
|
For the FROM address:
|
|
|
|
If it's on the parent side, reject if it's prefixed with hostname .. "/",
|
|
otherwise prefix it with "^".
|
|
If it's on the child side, reject if it's prefixed with "^",
|
|
otherwise prefix it with hostname .. "/".
|
|
|
|
For the TO address:
|
|
|
|
If it's on the parent side, reject unless prefixed with hostname .. "/",
|
|
otherwise remove that.
|
|
(Optionally, if the name is "*", bypass this rule completely.
|
|
This is not recommended, though, as this allows sending a "complete broadcast packet" via "[some amount of ^]*".)
|
|
|
|
If it's on the child side, reject unless prefixed with "^",
|
|
otherwise remove that.
|
|
(Optionally, if the name is "^*", reject anyway.
|
|
This is a measure which you may or may not wish to take - if the above 'complete broadcast' possibility has been implemented, then it is a must.)
|
|
|
|
For the packet's general routing:
|
|
|
|
If it's on the parent side, run the rules above on the addresses,
|
|
and forward to child side if not rejected.
|
|
If it's on the child side, run the rules above on the addresses,
|
|
and forward to parent side if not rejected.
|
|
|
|
Notably, the hops field should be incremented as if going through a normal routing node -
|
|
this prevents system misconfiguration from causing a complete meltdown.
|
|
|
|
This introduces a simple hierarchial structure that does not require any
|
|
support code apart from in the nodes supporting the hierarchy.
|
|
There are only two downsides:
|
|
1. Nodes connected to two gateways
|
|
could have multiple addresses but believe they only have one
|
|
2. Nodes behind two nested gateways can address themselves in two ways
|
|
|
|
However, this should all work out as long as people make a deliberate
|
|
effort not to notice the hierarchial structure system in their code.
|
|
|
|
Specifically, problem 2 only causes an issue should some nodes not
|
|
directly involved in gateway activities be
|
|
attempting to parse hierarchial addresses.
|
|
|
|
Possible uses of hierarchial gateways:
|
|
1. A safe (untrusting of servers in it) inter-server networking hub,
|
|
following the same protocol as everything else in Copper,
|
|
unlike certain competitors
|
|
2. ISPs within servers, perhaps those using the hubs
|
|
|
|
|
|
Errata:
|
|
|
|
Previous versions of the spec used "<" - this was not very usable from most shells on most operating systems.
|
|
It has been replaced with "^".
|
|
It was not explicitly specified that this was not the only way of doing things - this has been corrected.
|