| Network Working Group | |
| Internet-Draft | Independant |
| Expires: July 5, 2020 | January 2, 2020 |
Hierarchically Located Addressing and Routing Protocol
draft-anonymous-rtgwg-hlarp-00
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.
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 (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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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.
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.
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 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.
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.
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 |
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.
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) |
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.
| 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 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. The next relay address is described in 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.
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.
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.
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 |
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 address that sent it. In an operation 2 message, there is no body, or the body is of length zero.
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.
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:
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.
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, 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.
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.