idnits 2.17.1 draft-anonymous-rtgwg-hlarp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2020) is 1575 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 424 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet-Draft Independant 4 Expires: July 5, 2020 January 2, 2020 6 Hierarchically Located Addressing and Routing Protocol 7 draft-anonymous-rtgwg-hlarp-00 9 Abstract 11 This internet-draft describes a protocol with an addressing scheme 12 where members of the internet are addressed by their physical 13 addresses and by an implementing internet router that can contact 14 them. The packets sent by the protocol include handshake messages, 15 client data, and the status of the data being sent. A routing 16 procedure is suggested according to special addresses that carry 17 information about the region of a router. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 5, 2020. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 1.1. Motivation 55 Allocated IP addresses require a fee, are only temporary, and require 56 an organization. An ISP can offer these services at a much greater 57 fee. This internet-draft attempts to provide the permanence of MAC 58 addresses and other types of physical addresses for the use of the 59 internet. The infrastructure for physical addressing is already in 60 place and already identifies a single transmitting machine. With IP, 61 transmitting machines are identified once more. The IP addresses are 62 distributed for routing purposes and for identification purposes, 63 although addressing for routing can be set up without identification. 65 1.2. Terminology 67 Rank - length of one coordinate 69 Root - no coordinates 71 Member - user of the HLARP network 73 Network Member - member that directly contacts a relay and 74 contacts at least one host member 76 Host Member - member that represents the user 78 Relay - router capable of transferring data between regions that 79 implements the described protocol 81 1.3. Scope 83 This draft focuses on routing and addressing. The described protocol 84 is to be operated between the physical and internet layers. The 85 draft provides a replacement for routing and addressing for IP but 86 for no other IP functionality. Other functionality is provided by 87 the internet header within a data packet. The described protocol 88 utilizes addressing features of the physical layer. 90 2. Draft Notes 92 This notice has been preserved because this is still a draft, and 93 this protocol is NOT standardized. The IETF does NOT permit 94 implementors that advertise conformance and/or implementation with 95 the described protocol. This does NOT specify a protocol, but 96 describe a proposed protocol to the readers. A mention of 97 specification of the discribed protocol has been accidentally 98 included and should be changed and interpreted as this is a 99 description. Any IANA registration requested has NOT been made. The 100 draft has been submitted using a Tor exit node and the owner of the 101 displayed IP address is NOT responsible for the content of this 102 document. The rules governing the IETF do NOT permit independant 103 publication due to the significant IANA registration of IPv14 104 (Section 6). 106 3. Addressing 108 In HLARP, two types of addresses are used. A member address is used 109 to identify a member of the network. Internet routers that wish to 110 abide by the protocol have no need to use a member address and need a 111 different address to route HLARP packets. A relay address is used to 112 identify an implementing relay in routing. 114 3.1. Relay Addressing 116 A relay address is comprised of two flags, a rank in the areal 117 hierarchy, an octet to specify the coordinate system, and two 118 coordinates. Relay addresses are used to locate the relay, and they 119 cover an area. Relays need no identification in their relay address 120 because the physical layer already identifies the relay. This area's 121 size is determined by both the mappings from physical locations to 122 coordinates, and the length of each coordinate. 124 This is the overview of an HLARP relay address. 126 +----------+--------------------------------------------------------+ 127 | Size | Description | 128 +----------+--------------------------------------------------------+ 129 | 1 bit | specifies if the location is the root rank | 130 | | | 131 | 3 bits | are reserved for future use (set to zero until | 132 | | further notice) | 133 | | | 134 | 4 bits | specify the length of each coordinate, minus one | 135 | | (pow(2,4) = 16 so 4 bits are used) | 136 | | | 137 | 8 bits | specify the coordinate system | 138 | | | 139 | 16 bits | specify the x coordinate | 140 | | | 141 | 16 bits | specify the y coordinate | 142 +----------+--------------------------------------------------------+ 143 A rank of 0 is the root rank and the length of each coordinate will 144 not be used, and can be set to 0. While using any other rank, the 145 constant number 1 is to be subtracted from the rank for storage. The 146 maximum 4-bit number is 15, and this rule is made to fit rank 16 into 147 the length field. 149 3.2. Member Addressing 151 Member addresses are used to identify the members of this network of 152 networks. These addresses are relay addresses and the physical 153 addresses used for communication in the physical layer. The relay 154 address is the address of a relay that can contact the member. The 155 member address is the address of one end of a route. This protocol 156 makes a temporary fix for network members that are unable to keep 157 track of the physical addresses of the host members. Future versions 158 should obselete this functionality. The member network that is able 159 to recieve messages from the closest relay is responsible for 160 allocation of 16-bit numbers to physical addresses using the network. 161 If the member network has functionality to keep track of connected 162 physical addresses, then the network should always give 0 in addition 163 to the member's physical address. The only reason for this is to 164 save transmittor power. 166 This table shows the layout of a member address. 168 +-----------+-------------------------------------------------------+ 169 | Size | Description | 170 +-----------+-------------------------------------------------------+ 171 | 48 bits | store a relay address that can contact the member | 172 | | | 173 | 16 bits | store the number of the host member as assigned by a | 174 | | network member | 175 | | | 176 | variable | stores the physical address (length of the address | 177 | | of the physical layer) | 178 +-----------+-------------------------------------------------------+ 180 4. Packets 182 An HLARP packet header consists of an special IP version specifier 183 (to prevent IP implementers from thinking that it's an IP packet), a 184 protocol number, a version number, some flags, a source, and 185 destination. The data will be assumed to be an IP packet with the 186 header, to use functionality from the Internet Protocol that this 187 protocol doesn't provide. 189 +-----------+-------------------------------------------------------+ 190 | Size | Description | 191 +-----------+-------------------------------------------------------+ 192 | 4 bits | always equal to 14 | 193 | | | 194 | 8 bits | determine the experimental/other protocol (1 in | 195 | | HLARP) | 196 | | | 197 | 4 bits | determine the HLARP version (this defines version 0) | 198 | | | 199 | 1 bit | determines the type of source address (0 for member, | 200 | | 1 for relay) | 201 | | | 202 | 1 bit | determines the type of destination address (0 for | 203 | | member, 1 for relay) | 204 | | | 205 | 1 bit | determines if there is a next relay address (0 for | 206 | | none, 1 for relay) | 207 | | | 208 | 2 bits | are reserved for future use (any value) | 209 | | | 210 | 3 bits | determine the operation ID | 211 | | | 212 | 6 bits | are also reserved for future use (any value) | 213 | | | 214 | 10 bits | form the addition of the 3 preceeding octets | 215 | | | 216 | 32 bits | form the CRC-32 of all remaining octets | 217 | | | 218 | variable | source address (member address or relay address) | 219 | | | 220 | 48 bits | next relay address (not always allocated in the | 221 | | packet) | 222 | | | 223 | variable | destination address (member address or relay | 224 | | address) | 225 +-----------+-------------------------------------------------------+ 227 The first two octets specify that the header is for HLARP version 0. 228 There is an allowance for other protocols and for updates to this 229 protocol. The protocol number is to allow other protocols to 230 differentiate themselves and another number may be allocated for use 231 in any context. 233 The next 6 bytes give error checking capability and ensure data 234 integrity. The first number is calculated by adding each preceeding 235 octet into a 10-bit number. The remaining 4 bytes give the result of 236 a CRC-32 computation of the contents of all of the next octet. This 237 gives partial error checking capability on the addresses and data. 239 The next octets determine the type of source address, destination 240 address, and if the packet is currently being routed through a relay. 241 The source and destination address may be a member or a relay, but a 242 next relay address has no format options and defaults to a relay 243 address. 245 The source and destination address are to be stored as stated in 246 section 3 (Section 3). The next relay address is described in 247 section 3.1 (Section 3.1), and can not be a member address. The 248 address after the source addresss will be guaranteed to be the 249 address that needs to process the packet. 251 There are different operations that can be performed, like data 252 transfer, status reporting, pinging, and searching for a relay. The 253 operations change how the information following the header is to be 254 interpreted. 256 4.1. Operation 0 - DATA 258 Operation 0 will be a very frequently used operation, hence the 259 number with no one bits. The body of a data packet would have the IP 260 header and body. The IP address fields would still allocated in the 261 packet to ease adjustments by implementors of this protocol that 262 already use IP. This is also to save transmittor power. 264 4.2. Operation 1 - STATUS 266 Operation 1 is a message sent to a member that notifies it of the 267 status of the operation 0 message that it sent. Implementing relays 268 do not need to be send the operation 1 message to members. A message 269 of operation 1 has a single octet for the body. The octet is a 270 number that is selected from the list at the section's bottom and may 271 be expanded in future versions. If status code 8, 9, or 10 is used, 272 then the relay will give a null-terminated string appended to its 273 8-bit length. A zero-length string would be permitted, in which case 274 a null character is appended instead of a string. 276 The provided status code could be important information for the user 277 regaining access. Even successful transmissions should be responded 278 to with a status code for debugging purposes and to discourage DoS 279 attacks. 281 This table shows the status codes that are to be in use. 283 +-----------------+--------------+----------------------------------+ 284 | Name | Enumeration | Description | 285 +-----------------+--------------+----------------------------------+ 286 | DELIVERED | 0 | The message was | 287 | | | delivered | 288 | | | | 289 | BLOCKED | 1 | The message was | 290 | | | forcibly blocked by the relay | 291 | | | operator | 292 | | | | 293 | UNSERVICED | 2 | The destination | 294 | | | relay can not be reached | 295 | | | | 296 | UNUSED_HOST_ID | 3 | The specified | 297 | | | host ID is unassigned by the | 298 | | | network | 299 | | | | 300 | NONMEMBER | 4 | The given address | 301 | | | is not a serviced member | 302 | | | | 303 | BANNED_UNPAID | 5 | The relay awaits | 304 | | | member's service payment | 305 | | | | 306 | BANNED_LEGAL | 6 | The relay operator | 307 | | | is avoiding a legal risk | 308 | | | | 309 | DELIVERED_OTHER | 7 | The message was | 310 | | | sent unusually | 311 | | | | 312 | UNABLE_OTHER | 8 | The message can not | 313 | | | be sent for another reason | 314 | | | | 315 | BANNED_OTHER | 9 | The member is | 316 | | | banned for another reason | 317 +-----------------+--------------+----------------------------------+ 319 4.3. Operation 2 - RELAY_REQ 321 Operation 2 is a member's request for relay services. The 322 destination may be a relay or a member. This operation is for a 323 member that is trying to get direct relay service and multiple relays 324 on the medium. If the member is searching, then the physical layer 325 will broadcast the message with operation 2 and use a multicast 326 address for the physical recipient. If the member has selected a 327 relay offer to accept, then it wil send the message to the physical 328 address that sent it. In an operation 2 message, there is no body, 329 or the body is of length zero. 331 4.4. Operation 3 - RELAY_OFFER 333 Operation 3 notifies the member of an offer of service. Any 334 unrequested responses are to be treated as DoS attacks if repeated. 335 There is no body to a message with operation 3 and the length is 336 zero. 338 5. Routing 340 The routing process is short-sided and depends on each relay. The 341 sending member doesn't need to generate an entire route in order to 342 send the data to the next relay. This is a 4-step process that a 343 single implementing relay could use. This process is a suggestion 344 that was devised according to the addressing scheme. A relay can be 345 called out for not reaching certain destinations and recieve less- 346 than-desirable traffic. 348 Step 1: 350 When a relay recieves a packet and runs is willing and ready to serve 351 the client, then it will determine the next relay or destination. If 352 the coordinate system, x coordinate, and y coordinate of itself and 353 of the destination matches, and the length of itself is the same, 354 then the relay will relay the packet to the destination. 356 Step 2: 358 Otherwise, the relay must determine the next relay in the route. If 359 the coordinate system doesn't match, then the relay will target the 360 root relay (setting the root relay as the target relay). 362 Step 3: 364 If the coordinate system matches, then the relay will perform an XNOR 365 operation on the x coordinate of the current relay and the target 366 relay. The same XNOR operation will be performed on the y coordinate 367 of both relays. Both results will be combined with an AND operation, 368 resulting in a single descriptor of the length. The relay will count 369 the amount of consecutive one bits, and start from the left. The 370 amount of consecutive one bits is the length. The relay will still 371 need to subract 1 from the length for storage and transmission. 373 Step 4: 375 The lengths of the current and target relay should be tested if they 376 differ by a number that is greater than 4, so that the current relay 377 doesn't need to be very accurate. The lengths should differ by 4 if 378 the length difference is greater than 4. This step will not change 379 the evaluation of l1 > l2 where l1 is the length of the current relay 380 and l2 is the length of the target relay. 382 6. IANA Considerations 384 This section is NOT an active request, as this document is an 385 Internet-Draft. DO NOT update ANY registries according to this 386 section. This section is ONLY for people who wish to publish this as 387 an RFC so for their convenience in changing to RFCs. 389 This draft would request the assignment of IPv14 in the Version 390 Numbers [1], for the experimental and other protocols. An 8-bit list 391 is requested for the enumerated protocols themselves. This list is 392 the protocols list for any other protocols of this scope to use. A 393 4-bit list is also requested, independant of the other list, for the 394 HLARP version numbers. 396 IANA would be tasked with mapping the latitude-longtitude coordinate 397 system of Earth with a 2-dimensional 16-bit-per-dimension coordinate 398 system. The allocation of sub-area IDs has no dependance on IANA. 399 IANA is requested to plot the points and to plot powers of two and 400 their decrements to align with real-world borders and obstacles (for 401 example, x = 32767 and 32768 could align with the borders of Europe 402 and the Americas). For anti-tracking purposes, the location 403 information can not be more accurate than current IP address 404 trackers. This would make the assignments vary in length, and the 405 rest of the x and y field can be filled with zeros, regardless of 406 where the network member locates itself within the specified area. 408 7. Security Considerations 410 Within the scope of this draft are the security issues of 411 authentication and eavesdropping. Data integrity and undeniable 412 service are issues for all areas of the internet. This draft, while 413 not giving DoS protection, discourages people from launching these 414 attacks themselves. The status operation is a feature that would 415 flood an attacker's medium of transmission. The protocol gives weak 416 verification for the integrity of the data. The protocol gives no 417 protection from attackers that wish to read or alter the data. It is 418 expected that the transport layer will provide data security. 420 8. References 422 8.1. URIs 424 [1] https://www.iana.org/assignments/version-numbers/version- 425 numbers.xhtml 427 Author's Address 429 anonymous 430 Independant 432 Email: 5265644D61736F6E@gmail.com