Internet DRAFT - draft-anonymous-rtgwg-hlarp
draft-anonymous-rtgwg-hlarp
Network Working Group
Internet-Draft Independant
Expires: July 5, 2020 January 2, 2020
Hierarchically Located Addressing and Routing Protocol
draft-anonymous-rtgwg-hlarp-00
Abstract
This internet-draft describes a protocol with an addressing scheme
where members of the internet are addressed by their physical
addresses and by an implementing internet router that can contact
them. The packets sent by the protocol include handshake messages,
client data, and the status of the data being sent. A routing
procedure is suggested according to special addresses that carry
information about the region of a router.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 5, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Expires July 5, 2020 [Page 1]
Internet-Draft HLARP January 2020
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
1. Introduction
1.1. Motivation
Allocated IP addresses require a fee, are only temporary, and require
an organization. An ISP can offer these services at a much greater
fee. This internet-draft attempts to provide the permanence of MAC
addresses and other types of physical addresses for the use of the
internet. The infrastructure for physical addressing is already in
place and already identifies a single transmitting machine. With IP,
transmitting machines are identified once more. The IP addresses are
distributed for routing purposes and for identification purposes,
although addressing for routing can be set up without identification.
1.2. Terminology
Rank - length of one coordinate
Root - no coordinates
Member - user of the HLARP network
Network Member - member that directly contacts a relay and
contacts at least one host member
Host Member - member that represents the user
Relay - router capable of transferring data between regions that
implements the described protocol
1.3. Scope
This draft focuses on routing and addressing. The described protocol
is to be operated between the physical and internet layers. The
draft provides a replacement for routing and addressing for IP but
for no other IP functionality. Other functionality is provided by
the internet header within a data packet. The described protocol
utilizes addressing features of the physical layer.
2. Draft Notes
This notice has been preserved because this is still a draft, and
this protocol is NOT standardized. The IETF does NOT permit
implementors that advertise conformance and/or implementation with
the described protocol. This does NOT specify a protocol, but
Expires July 5, 2020 [Page 2]
Internet-Draft HLARP January 2020
describe a proposed protocol to the readers. A mention of
specification of the discribed protocol has been accidentally
included and should be changed and interpreted as this is a
description. Any IANA registration requested has NOT been made. The
draft has been submitted using a Tor exit node and the owner of the
displayed IP address is NOT responsible for the content of this
document. The rules governing the IETF do NOT permit independant
publication due to the significant IANA registration of IPv14
(Section 6).
3. Addressing
In HLARP, two types of addresses are used. A member address is used
to identify a member of the network. Internet routers that wish to
abide by the protocol have no need to use a member address and need a
different address to route HLARP packets. A relay address is used to
identify an implementing relay in routing.
3.1. Relay Addressing
A relay address is comprised of two flags, a rank in the areal
hierarchy, an octet to specify the coordinate system, and two
coordinates. Relay addresses are used to locate the relay, and they
cover an area. Relays need no identification in their relay address
because the physical layer already identifies the relay. This area's
size is determined by both the mappings from physical locations to
coordinates, and the length of each coordinate.
This is the overview of an HLARP relay address.
+----------+--------------------------------------------------------+
| Size | Description |
+----------+--------------------------------------------------------+
| 1 bit | specifies if the location is the root rank |
| | |
| 3 bits | are reserved for future use (set to zero until |
| | further notice) |
| | |
| 4 bits | specify the length of each coordinate, minus one |
| | (pow(2,4) = 16 so 4 bits are used) |
| | |
| 8 bits | specify the coordinate system |
| | |
| 16 bits | specify the x coordinate |
| | |
| 16 bits | specify the y coordinate |
+----------+--------------------------------------------------------+
Expires July 5, 2020 [Page 3]
Internet-Draft HLARP January 2020
A rank of 0 is the root rank and the length of each coordinate will
not be used, and can be set to 0. While using any other rank, the
constant number 1 is to be subtracted from the rank for storage. The
maximum 4-bit number is 15, and this rule is made to fit rank 16 into
the length field.
3.2. Member Addressing
Member addresses are used to identify the members of this network of
networks. These addresses are relay addresses and the physical
addresses used for communication in the physical layer. The relay
address is the address of a relay that can contact the member. The
member address is the address of one end of a route. This protocol
makes a temporary fix for network members that are unable to keep
track of the physical addresses of the host members. Future versions
should obselete this functionality. The member network that is able
to recieve messages from the closest relay is responsible for
allocation of 16-bit numbers to physical addresses using the network.
If the member network has functionality to keep track of connected
physical addresses, then the network should always give 0 in addition
to the member's physical address. The only reason for this is to
save transmittor power.
This table shows the layout of a member address.
+-----------+-------------------------------------------------------+
| Size | Description |
+-----------+-------------------------------------------------------+
| 48 bits | store a relay address that can contact the member |
| | |
| 16 bits | store the number of the host member as assigned by a |
| | network member |
| | |
| variable | stores the physical address (length of the address |
| | of the physical layer) |
+-----------+-------------------------------------------------------+
4. Packets
An HLARP packet header consists of an special IP version specifier
(to prevent IP implementers from thinking that it's an IP packet), a
protocol number, a version number, some flags, a source, and
destination. The data will be assumed to be an IP packet with the
header, to use functionality from the Internet Protocol that this
protocol doesn't provide.
Expires July 5, 2020 [Page 4]
Internet-Draft HLARP January 2020
+-----------+-------------------------------------------------------+
| Size | Description |
+-----------+-------------------------------------------------------+
| 4 bits | always equal to 14 |
| | |
| 8 bits | determine the experimental/other protocol (1 in |
| | HLARP) |
| | |
| 4 bits | determine the HLARP version (this defines version 0) |
| | |
| 1 bit | determines the type of source address (0 for member, |
| | 1 for relay) |
| | |
| 1 bit | determines the type of destination address (0 for |
| | member, 1 for relay) |
| | |
| 1 bit | determines if there is a next relay address (0 for |
| | none, 1 for relay) |
| | |
| 2 bits | are reserved for future use (any value) |
| | |
| 3 bits | determine the operation ID |
| | |
| 6 bits | are also reserved for future use (any value) |
| | |
| 10 bits | form the addition of the 3 preceeding octets |
| | |
| 32 bits | form the CRC-32 of all remaining octets |
| | |
| variable | source address (member address or relay address) |
| | |
| 48 bits | next relay address (not always allocated in the |
| | packet) |
| | |
| variable | destination address (member address or relay |
| | address) |
+-----------+-------------------------------------------------------+
The first two octets specify that the header is for HLARP version 0.
There is an allowance for other protocols and for updates to this
protocol. The protocol number is to allow other protocols to
differentiate themselves and another number may be allocated for use
in any context.
The next 6 bytes give error checking capability and ensure data
integrity. The first number is calculated by adding each preceeding
octet into a 10-bit number. The remaining 4 bytes give the result of
Expires July 5, 2020 [Page 5]
Internet-Draft HLARP January 2020
a CRC-32 computation of the contents of all of the next octet. This
gives partial error checking capability on the addresses and data.
The next octets determine the type of source address, destination
address, and if the packet is currently being routed through a relay.
The source and destination address may be a member or a relay, but a
next relay address has no format options and defaults to a relay
address.
The source and destination address are to be stored as stated in
section 3 (Section 3). The next relay address is described in
section 3.1 (Section 3.1), and can not be a member address. The
address after the source addresss will be guaranteed to be the
address that needs to process the packet.
There are different operations that can be performed, like data
transfer, status reporting, pinging, and searching for a relay. The
operations change how the information following the header is to be
interpreted.
4.1. Operation 0 - DATA
Operation 0 will be a very frequently used operation, hence the
number with no one bits. The body of a data packet would have the IP
header and body. The IP address fields would still allocated in the
packet to ease adjustments by implementors of this protocol that
already use IP. This is also to save transmittor power.
4.2. Operation 1 - STATUS
Operation 1 is a message sent to a member that notifies it of the
status of the operation 0 message that it sent. Implementing relays
do not need to be send the operation 1 message to members. A message
of operation 1 has a single octet for the body. The octet is a
number that is selected from the list at the section's bottom and may
be expanded in future versions. If status code 8, 9, or 10 is used,
then the relay will give a null-terminated string appended to its
8-bit length. A zero-length string would be permitted, in which case
a null character is appended instead of a string.
The provided status code could be important information for the user
regaining access. Even successful transmissions should be responded
to with a status code for debugging purposes and to discourage DoS
attacks.
Expires July 5, 2020 [Page 6]
Internet-Draft HLARP January 2020
This table shows the status codes that are to be in use.
+-----------------+--------------+----------------------------------+
| Name | Enumeration | Description |
+-----------------+--------------+----------------------------------+
| DELIVERED | 0 | The message was |
| | | delivered |
| | | |
| BLOCKED | 1 | The message was |
| | | forcibly blocked by the relay |
| | | operator |
| | | |
| UNSERVICED | 2 | The destination |
| | | relay can not be reached |
| | | |
| UNUSED_HOST_ID | 3 | The specified |
| | | host ID is unassigned by the |
| | | network |
| | | |
| NONMEMBER | 4 | The given address |
| | | is not a serviced member |
| | | |
| BANNED_UNPAID | 5 | The relay awaits |
| | | member's service payment |
| | | |
| BANNED_LEGAL | 6 | The relay operator |
| | | is avoiding a legal risk |
| | | |
| DELIVERED_OTHER | 7 | The message was |
| | | sent unusually |
| | | |
| UNABLE_OTHER | 8 | The message can not |
| | | be sent for another reason |
| | | |
| BANNED_OTHER | 9 | The member is |
| | | banned for another reason |
+-----------------+--------------+----------------------------------+
4.3. Operation 2 - RELAY_REQ
Operation 2 is a member's request for relay services. The
destination may be a relay or a member. This operation is for a
member that is trying to get direct relay service and multiple relays
on the medium. If the member is searching, then the physical layer
will broadcast the message with operation 2 and use a multicast
address for the physical recipient. If the member has selected a
relay offer to accept, then it wil send the message to the physical
Expires July 5, 2020 [Page 7]
Internet-Draft HLARP January 2020
address that sent it. In an operation 2 message, there is no body,
or the body is of length zero.
4.4. Operation 3 - RELAY_OFFER
Operation 3 notifies the member of an offer of service. Any
unrequested responses are to be treated as DoS attacks if repeated.
There is no body to a message with operation 3 and the length is
zero.
5. Routing
The routing process is short-sided and depends on each relay. The
sending member doesn't need to generate an entire route in order to
send the data to the next relay. This is a 4-step process that a
single implementing relay could use. This process is a suggestion
that was devised according to the addressing scheme. A relay can be
called out for not reaching certain destinations and recieve less-
than-desirable traffic.
Step 1:
When a relay recieves a packet and runs is willing and ready to serve
the client, then it will determine the next relay or destination. If
the coordinate system, x coordinate, and y coordinate of itself and
of the destination matches, and the length of itself is the same,
then the relay will relay the packet to the destination.
Step 2:
Otherwise, the relay must determine the next relay in the route. If
the coordinate system doesn't match, then the relay will target the
root relay (setting the root relay as the target relay).
Step 3:
If the coordinate system matches, then the relay will perform an XNOR
operation on the x coordinate of the current relay and the target
relay. The same XNOR operation will be performed on the y coordinate
of both relays. Both results will be combined with an AND operation,
resulting in a single descriptor of the length. The relay will count
the amount of consecutive one bits, and start from the left. The
amount of consecutive one bits is the length. The relay will still
need to subract 1 from the length for storage and transmission.
Step 4:
Expires July 5, 2020 [Page 8]
Internet-Draft HLARP January 2020
The lengths of the current and target relay should be tested if they
differ by a number that is greater than 4, so that the current relay
doesn't need to be very accurate. The lengths should differ by 4 if
the length difference is greater than 4. This step will not change
the evaluation of l1 > l2 where l1 is the length of the current relay
and l2 is the length of the target relay.
6. IANA Considerations
This section is NOT an active request, as this document is an
Internet-Draft. DO NOT update ANY registries according to this
section. This section is ONLY for people who wish to publish this as
an RFC so for their convenience in changing to RFCs.
This draft would request the assignment of IPv14 in the Version
Numbers [1], for the experimental and other protocols. An 8-bit list
is requested for the enumerated protocols themselves. This list is
the protocols list for any other protocols of this scope to use. A
4-bit list is also requested, independant of the other list, for the
HLARP version numbers.
IANA would be tasked with mapping the latitude-longtitude coordinate
system of Earth with a 2-dimensional 16-bit-per-dimension coordinate
system. The allocation of sub-area IDs has no dependance on IANA.
IANA is requested to plot the points and to plot powers of two and
their decrements to align with real-world borders and obstacles (for
example, x = 32767 and 32768 could align with the borders of Europe
and the Americas). For anti-tracking purposes, the location
information can not be more accurate than current IP address
trackers. This would make the assignments vary in length, and the
rest of the x and y field can be filled with zeros, regardless of
where the network member locates itself within the specified area.
7. Security Considerations
Within the scope of this draft are the security issues of
authentication and eavesdropping. Data integrity and undeniable
service are issues for all areas of the internet. This draft, while
not giving DoS protection, discourages people from launching these
attacks themselves. The status operation is a feature that would
flood an attacker's medium of transmission. The protocol gives weak
verification for the integrity of the data. The protocol gives no
protection from attackers that wish to read or alter the data. It is
expected that the transport layer will provide data security.
Expires July 5, 2020 [Page 9]
Internet-Draft HLARP January 2020
8. References
8.1. URIs
[1] https://www.iana.org/assignments/version-numbers/version-
numbers.xhtml
Author's Address
anonymous
Independant
Email: 5265644D61736F6E@gmail.com
Expires July 5, 2020 [Page 10]
