mirror of
https://github.com/XeonSquared/OC-Copper.git
synced 2024-11-08 19:08:05 +11:00
43 lines
1.6 KiB
Groff
43 lines
1.6 KiB
Groff
Copper Protocol :: Hierarchial Gateways
|
|
20kdc, 2017
|
|
|
|
"Hierarchial Gateways" are a system for ISP-like bodies to prevent their
|
|
users from causing havoc.
|
|
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 "<" and forward to child side.
|
|
If it's on the child side, reject if it's prefixed with "<",
|
|
otherwise prefix it with hostname .. "/" and forward to parent side.
|
|
|
|
For the TO address:
|
|
|
|
If it's on the parent side, reject unless prefixed with hostname .. "/",
|
|
otherwise remove that and forward to child side.
|
|
If it's on the child side, reject unless prefixed with "<",
|
|
otherwise remove that and forward to parent side.
|
|
|
|
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
|