idnits 2.17.1 draft-eromenko-ipff-addressing-05.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 587 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 457: '...s, here are some RECOMMENDED addresses...' RFC 2119 keyword, line 466: '...t of "999" limit MUST be done at Trans...' RFC 2119 keyword, line 470: '...Additionally, it MUST be enforced by b...' RFC 2119 keyword, line 477: '... and middleboxes MAY check this 999 fi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 213 has weird spacing: '...address is ...' == Line 216 has weird spacing: '...-length is a...' -- The document date (2017-03-29) is 2584 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? 'IPFF' on line 99 looks like a reference -- Missing reference section? 'CIDR' on line 206 looks like a reference -- Missing reference section? 'IPFF-ARPv5' on line 435 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - Addressing Architecture", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 8 A. Eromenko 9 September 2016 11 IP Version 5 Addressing Architecture 12 aka Internet Protocol "Five Fields" (IP-FF; draft) 14 Abstract 16 This specification defines the addressing architecture of the IP 17 Version 5 (IPFF) protocol. The document includes the IPFF addressing 18 model, text representations of IPFF addresses, definition of IPFF 19 unicast addresses, anycast addresses, and multicast addresses. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 Copyright Notice 38 Copyright (c) 2016 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 (http://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 Table of Contents 53 1. Introduction ....................................................2 54 2. IPFF Addressing .................................................2 55 2.1. Addressing Model ...........................................3 56 2.2. Text Representation of Addresses ...........................4 57 2.3. Text Representation of Address Prefixes ....................5 58 2.4. Address Type Identification ................................6 59 2.5. Unicast Addresses ..........................................6 60 2.5.1. Private addresses ...................................7 61 2.5.1. AutoIP addresses ....................................8 62 2.5.3. The Unspecified Address .............................9 63 2.5.4. The Loopback Address ................................9 64 2.5.5. Global Unicast Addresses ............................9 65 2.6. Anycast Addresses .........................................12 66 2.6.1. Required Anycast Address ...........................12 67 2.7. Multicast Addresses .......................................13 68 2.7.1. Pre-Defined Multicast Addresses ....................15 69 2.7.2. Silent Multicast Addresses.......................... 70 2.8. Broadcast Address ......................................... 71 2.9. A Node's Required Addresses ............................... 72 3. Routing and Invalid Addresses .................................. 73 3.1. Default Gateway ........................................... 74 3.2. Special meaning of /50 subnet prefix ...................... 75 3.3. Non-contiguous wildcard masks ............................. 76 3.4. Not all subnets are born equal ............................ 77 4. Acknowledgements ............................................... 79 1. Introduction 81 This specification defines the addressing architecture of the IP 82 Version 5 protocol. It includes the basic formats for the various 83 types of IPFF addresses (unicast, anycast, and multicast). 85 2. IPFF Addressing 87 The main benefit of IPFF, is that it looks familiar to all, 88 whom ever used IPv4, just with an extra field. So "five fields". 90 Examples: 92 192.168.510.971.11 94 10.0.0.0.1 96 382.201.769.25.133 98 IPFF addresses are 50-bit identifiers for interfaces and sets of 99 interfaces (where "interface" is as defined in Section 2 of [IPFF]). 100 Each field is 10-bits wide, but due to human-memory constraits, 101 values are limited to "999" per field. 103 Why go to the great length of dis-guard perfectly useable bits? 104 Why not up to 1023.1023.1023.1023.1023, as 10-bit fields imply? 105 Bits in IPFF are a bit under-utilized. 107 Well, IP-FF was designed with humans in mind. 108 Limit of three-digits allows for easy readability, comparison, 109 memorization and visualizing network topology in human memory, 110 just like in IPv4, unlike IPv6. 111 This is a small sacrifice of total address range with 112 a huge human benefit. 114 And in modern computing devices are typically represented by 64-bit 115 unsigned integer, pre-padded with 14-bits of zeroes. 117 There are several types of addresses: 119 Unicast: An identifier for a single interface. A packet sent to a 120 unicast address is delivered to the interface identified 121 by that address. 123 Anycast: An identifier for a set of interfaces (typically 124 belonging to different nodes). A packet sent to an 125 anycast address is delivered to one of the interfaces 126 identified by that address (the "nearest" one, according 127 to the routing protocols' measure of distance). 129 Traditional Multicast: 131 An identifier for a set of interfaces (typically 132 belonging to different nodes). A packet sent to a 133 multicast address is delivered to all interfaces 134 identified by that address. 135 Traditional Multicast mandates IGMP advertisement, 136 and allows for IGMP snooping. 138 Silent Multicast: 140 An identifier for a set of interfaces (typically 141 belonging to different nodes). A packet sent to a 142 multicast address is delivered to all interfaces 143 identified by that address. 144 Silent Multicast doesn't do any IGMP advertisement, 145 and it's done for simplicity. 146 Typically has local-link significance. 148 Broadcast: An identifier for all node's interfaces 149 on a local-link. 151 Unlike IPv6, the use of IGMP is required only for Traditional 152 Multicast; That is a system can join a Multicast group, 153 but not send any message about it. 154 This is called "silent multicast mode". 156 In IPFF, all zeros and all ones are legal values for any field, 157 unless specifically excluded. Specifically, prefixes may contain, or 158 end with, zero-valued fields. 160 2.1. Addressing Model 162 IPFF addresses of all types are assigned to interfaces, not nodes. 163 An IPFF unicast address refers to a single interface. Since each 164 interface belongs to a single node, any of that node's interfaces' 165 unicast addresses may be used as an identifier for the node. 167 A single interface may also have multiple IPFF addresses of any type 168 (unicast, anycast, and multicast), but typically has only one 169 primary unicast address. 171 Currently, IPFF continues the IPv4 model in that a subnet prefix is 172 associated with one link. Multiple subnet prefixes may be assigned 173 to the same link, one per IP address. 175 2.2. Text Representation of Addresses 177 There are two conventional forms for representing IPFF addresses as 178 text strings: 180 1. The preferred form is x.x.x.x.x, where the 'x's are one to 181 three decimal digits. 183 2. Special case: shortening 184 In order to make writing addresses containing zero fields 185 easier, a special syntax is available to compress the zeros. 186 The use of ".." indicates fields of 10 bits of zeros. 188 For example, the following addresses 190 0.0.0.0.1 the loopback address 191 0.0.0.0.0 the unspecified address 193 may be represented as 195 ..1 the loopback address 196 ..0 the unspecified address 198 Note, that this shortened form is allowed only for loopback and 199 unspecified addresses, as a unicast & multicast are unlikely to have 200 too many zeroes to warrant a special case. 202 2.3. Text Representation of Address Prefixes 204 The text representation of IPFF address prefixes is similar to the 205 way IPv4 address prefixes are written in Classless Inter-Domain 206 Routing (CIDR) notation [CIDR]. An IPFF address prefix is 207 represented by the notation: 209 IPFF-address/prefix-length 211 where 213 IPFF-address is an IPFF address in any of the notations listed 214 in Section 2.2. 216 prefix-length is a decimal value specifying how many of the 217 leftmost contiguous bits of the address comprise 218 the prefix. 40 is default, if not specified. 219 That means, 4 fields for the network portion, and 220 one field of 10-bits for the hosts. 221 This is an equivalent of an IPv4 subnet mask. 223 Examples: 225 192.168.510.971.11/30 227 10.0.0.0.1 (implies /40) 229 382.201.769.25.133/34 231 2.4. Address Type Identification 233 The type of an IPFF address is identified by the high-order bits of 234 the address, as follows: 236 Address type Binary prefix IPFF notation Section 237 ------------ ------------- ------------- ------- 238 Unspecified 00...0 (50 bits) ..0/50 2.5.2 239 Loopback 00...1 (50 bits) ..1/50 2.5.3 240 Silent Multicast 01100011 000001001 99.9../20 2.7 241 Traditional Multicast 01100011 000001000 99.8../20 2.7 242 Broadcast 99.9.0.0.1 2.8 243 Unicast (everything else) 245 Anycast addresses are taken from the unicast address spaces (of any 246 scope) and are not syntactically distinguishable from unicast 247 addresses. 249 2.5. Unicast Addresses 251 IPFF unicast addresses are aggregatable with prefixes of arbitrary 252 bit-length, similar to IPv6 and IPv4 addresses under Classless 253 Inter-Domain Routing. 255 2.5.1. Private addresses 257 Similarly to IPv4 private addresses defined in RFC-1918, IPFF has 258 several: 260 10.0.0.0.0 - 10.999.999.999.999 (10.x.x.x.x/10 prefix) 262 172.16.0.0.0 - 172.31.999.999.999 (172.16-31.x.x.x/16 prefix) 264 192.168.0.0.0 - 192.168.999.999.999 (192.168.x.x.x/20 prefix) 266 Those were chosen to be visually similar to their IPv4 counterparts, 267 mainly to simplify migration from current IPv4 networks. 269 Those address ranges must not be routed on the Internet, but 270 they can be routed inside an organization. 272 Private addresses are intended for Enterprises that are either not 273 connected to the Internet, or for hosts that are hidden nehind a 274 NAT (Network Address Translation) device, typically a router. 276 An enterprise that decides to use IP addresses out of the address 277 space defined in this document can do so without any coordination 278 with IANA or an Internet registry. The address space can thus be used 279 by many enterprises. Addresses within this private address space will 280 only be unique within the enterprise, or the set of enterprises which 281 choose to cooperate over this space so they may communicate with each 282 other in their own private internet. 284 2.5.2. AutoIP / link-local unicast addresses 286 In addition, for Auto IP (aka Zeroconf aka Stateless DHCP aka 287 optional link-local addresses), another range was defined: 289 0.169.254.x.x/30 291 This address ranges should not be routed on the Internet, and 292 not inside an organization. 293 Those are considered unique only in a layer-2 broadcast domain, link 294 scope, therefore should not pass a router without a network address 295 translation. 297 Because link-local addresses are not required in IPFF, and not 298 recommended, the procedure of getting or generating them is not 299 described in this document. The packet originating from those 300 addresses should have a TTL value of 1. 302 2.5.3. The Unspecified Address 304 The address 0.0.0.0.0 is called the unspecified address. It 305 must never be assigned to any node. It indicates the absence of an 306 address. One example of its use is in the Source Address field of 307 any IPFF packets sent by an initializing host before it has learned 308 its own address. 310 The unspecified address must not be used as the destination address 311 of IPFF packets or in IPFF Routing headers. An IPFF packet with a 312 source address of unspecified must never be forwarded by an IPFF 313 router. 315 2.5.4. The Loopback Address 317 The unicast address 0.0.0.0.1/50 is called the loopback address. 318 Can be shortened to ..1 on input. 320 It may be used by a node to send an IPFF packet to itself. It must 321 not be assigned to any physical interface. 323 The loopback address must not be used as the source address in IPFF 324 packets that are sent outside of a single node. An IPFF packet with 325 a destination address of loopback must never be sent outside of a 326 single node and must never be forwarded by an IPFF router. A packet 327 received on an interface with a destination address of loopback must 328 be dropped. 330 2.5.5. Global Unicast Addresses 332 The can be anything that is not reserved for other purposes. 334 That is from 0.0.0.0.0 up to 999.999.999.999.999 but 335 excluding unspecified, loopback, multicast range, private IPs and 336 auto IPs. 338 Packets received with addresses above "999" in any one field should 339 be dropped. 341 2.6. Anycast Addresses 343 An IPFF anycast address is an address that is assigned to more than 344 one different node, with the 345 property that a packet sent to an anycast address is routed to the 346 "nearest" interface having that address, according to the routing 347 protocols' measure of distance. 349 Anycast addresses are allocated from the unicast address space, using 350 any of the defined unicast address formats. Thus, anycast addresses 351 are syntactically indistinguishable from unicast addresses. 353 The Router's job is to make sense of them, and route traffic to the 354 nearest node. 356 2.7. Multicast Addresses 358 An IPFF multicast address is an identifier for a group of interfaces 359 (typically on different nodes). An interface may belong to any 360 number of multicast groups. 362 They start with 99.x.x.x.x/10 364 In IPFF, we have four types of Multicast Addresses: 366 -Silent Multicast addresses, 367 -Private Multicast addresses, and 368 -Public Multicast addresses. 370 2.7.1. Pre-Defined Multicast Addresses 372 The following well-known multicast addresses are pre-defined. 374 Use of these group IDs for any other scope values, with the T flag 375 equal to 0, is not allowed. 377 Traditional Multicast address range defined: 379 99.8.0.0.x/30 381 Silent Multicast address range defined: 383 99.9.0.0.x/30 385 Private (Traditional) Multicast address range defined: 387 99.8.0.1.x/40 389 Reserved Multicast Addresses: 391 99.9.0.0.1 = All Nodes (= Broadcast) 392 99.8.0.0.2 = All Routers 393 99.9.0.0.3 = DHCP Servers 394 99.9.0.0.4 = DHCP Clients 396 Note, that "All Routers" use a traditional Multicast address with IGMP 397 advertisement, starting with 99.8.x 399 DHCP clients and servers, since are not generating lots of traffic, 400 do not need to advertise themselves for IGMP groups, and therefore 401 are "Silent listeners". They can be minimal embedded 402 devices, and don't have to implement the full IGMP protocol. 404 2.7.2. Silent Multicast Addresses 406 The big difference between silent (link-local) and traditional 407 Multicast addresses is "IGMP". 408 Silent multicast addresses are logically in-between 409 traditional multicast, that advertises itself by IGMP, 410 and broadcast that does not. 412 It means, that services, that nodes listening on Link-local 413 Multicast addresses *DO NOT* advertise that they have joined 414 Multicast group X, but nodes listening on Private Multicast 415 addresses *DO* advertise via IGMP. 417 Link-local Multicast address listeners also called 418 "silent multicast listeners". 420 "Silent Multicast" mode compared to traditional Multicast: 421 Benefit is two fold: simple IPFF implementations are possible, 422 as IGMP implementation is not needed, and if you want to receive 423 only a few packets, you really don't need to 424 flood whole network by IGMP advertisements. 425 So on the operating system level, a listener is still required 426 join a "Multicast group", but no advertisement is sent. 428 "Silent Multicast" mode compared to traditional broadcast: 429 ...nodes still get Layer 2 flooding, like broadcasts, but using 430 different IP addresses and different layer 2 addresses, nodes can 431 filter unnecessary traffic at layer 2 (by a node's Ethernet 432 controller, for example), instead of by Transport layer, saving 433 CPU time. 435 Ethernet examples are part of the [IPFF-ARPv5] spec. 437 2.8. Broadcast Address 439 99.9.0.0.1 the "All Nodes" silent multicast address doubles down 440 as a broadcast address, on a link-local scope. 442 This address is used by DAD (Duplicate Address Detection) mechanism, 443 and intended to be used only for network discovery purposes, 444 but most other traditionally-Broadcast applications should avoid 445 it's use, and opt for a Multicast or a Silent Multicast address 446 instead. 448 2.9. A Node's Required Addresses 450 Only few: 451 Loopback address. 0.0.0.0.1 452 Additionally, it must listen on the broadcast address of 99.9.0.0.1, 453 plus Node Multicast address. 454 At least one Unicast address, plus prefix (similar to subnet mask). 455 That's it ! 457 Beyond required addresses, here are some RECOMMENDED addresses: 458 -DNS address + backup DNS address(es) 459 -Default Gateway + backup Default Gateway(s) 461 3. Routing and Invalid Addresses 463 Routing should be done in full 50-bit addresses, but if any field is 464 bigger than 3 decimal digits "999", this traffic is invalid. 466 Actual enforcement of "999" limit MUST be done at Transport-layer, 467 for connection-oriented protocols only once by end-node, when socket 468 is created. (i.e incoming TCP session or outgoing TCP session, 469 only during and stage, and only for connection-oriented 470 Transport protocols). Additionally, it MUST be enforced by both 471 DNS clients and DNS servers. 473 Connectionless Transport protocols, such as UDP, are not required to 474 check this 999 limit. 475 This traffic is still invalid, but check is not actively enforced. 477 End-nodes and middleboxes MAY check this 999 field limit per- 478 packet, at the IP layer, and silently drop such invalid traffic. 479 No ICMP message needs to be sent. 480 Core Routers are not required to check this, for efficiency reasons. 482 3.1. Default Gateway 484 All-zero-bits subnet mask, or /0 prefix, together with 0.0.0.0.0 IP 485 address (or ..0 for short), means a default gateway. 487 3.2. Special meaning of /50 subnet prefix 489 All-one-bits subnet mask, or /50 prefix, which is the same written 490 differently, has a special meaning. It means that host has 491 access only to itself, or to a default gateway. 493 3.3. Non-contiguous wildcard masks 495 Some firewall vendors allow for Non-contiguous masks in IPv4, and 496 the same tradition can be kept with IPFF, but only for traffic 497 filtering purposes. 499 Wildcard mask is somewhat similar to the IPv4 subnet mask, but in 500 reverse. 1-bits are for *host portion*, while 0-bits are for *network 501 portion*. A Non-contiguous IPFF wildcard mask may look like: 502 0.0.1018.517.1023 504 All connectivity and routing-related decisions must use a prefix 505 notation, and thus be contiguous. 507 NOTE: While quad-digits per field (like .1023) are prohibited from 508 IPFF addresses, they are okay for the purpose of Wildcard masks. 510 3.4. Not all subnets are born equal 512 Let's take a /45 prefix, for example. 513 It means that I want to divide my 5th field into 32 subnets 514 with 32 hosts each. 516 10.0.0.0.0/45 subnet will have 32 hosts. (up to .31) 517 10.0.0.0.32/45 subnet will have 32 hosts. (up to .63) 518 ... 519 But what about the last subnet ? 521 10.0.0.0.992/45 subnet should have 32 hosts... 522 But it can't ! Why ? 524 Theoretically, it should have up to .1023 but the limit is .999, 525 This implies that some subnets may be not full, or not usable. 526 So this last subnet will have only 8 hosts ! (up to .999) 528 The limit was introduced to conserve *human* memory, which is more 529 precious than computer memory nowadays... So we, humans, need 530 to remember only three digits per field, instead of four. 532 4. Acknowledgements 534 The author would like to thank all previous IPv4 and IPv6 developers 535 for their hard work, and benefit for humanity. 536 This document is based on RFC-4291 (IPv6 addressing architecture) 537 and RFC-1918 (private IPv4 addressing). 539 Authors' Contacts 541 Alexey Eromenko 542 Israel 544 Skype: Fenix_NBK_ 545 EMail: al4321@gmail.com 546 Facebook: https://www.facebook.com/technologov 548 Based on the hard work of "Stephen E. Deering" and "Robert M. Hinden", 549 from IPv6 project, as well as all previous TCP/IP developers from DARPA. 551 Alexey 552 INTERNET-DRAFT 553 expiration date: 2017-03-29