INTERNET-DRAFT "Internet Protocol Five Fields - Addressing Architecture", Alexey Eromenko, 2015-12-10, expiration date: 2016-06-10 Intended status: Standards Track A. Eromenko December 2015 IP Version 5 Addressing Architecture aka Internet Protocol "Five Fields" (IP-FF; draft) Abstract This specification defines the addressing architecture of the IP Version 5 (IPFF) protocol. The document includes the IPFF addressing model, text representations of IPFF addresses, definition of IPFF unicast addresses, anycast addresses, and multicast addresses. 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 http://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 December 9, 2014. Copyright Notice Copyright (c) 2015 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 (http://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. Table of Contents 1. Introduction ....................................................2 2. IPFF Addressing .................................................2 2.1. Addressing Model ...........................................3 2.2. Text Representation of Addresses ...........................4 2.3. Text Representation of Address Prefixes ....................5 2.4. Address Type Identification ................................6 2.5. Unicast Addresses ..........................................6 2.5.1. Private addresses ...................................7 2.5.1. AutoIP addresses ....................................8 2.5.3. The Unspecified Address .............................9 2.5.4. The Loopback Address ................................9 2.5.5. Global Unicast Addresses ............................9 2.6. Anycast Addresses .........................................12 2.6.1. Required Anycast Address ...........................12 2.7. Multicast Addresses .......................................13 2.7.1. Pre-Defined Multicast Addresses ....................15 2.8. A Node's Required Addresses ...............................17 2.9. Non-contiguous wildcard masks.............................. 2.10. Not all subnets are born equal............................ 3. Routing and Invalid Addresses................................... 4. Acknowledgements ...............................................18 1. Introduction This specification defines the addressing architecture of the IP Version 5 protocol. It includes the basic formats for the various types of IPFF addresses (unicast, anycast, and multicast). 2. IPFF Addressing The main benefit of IPFF, is that it looks familiar to all, whom ever used IPv4, just with an extra field. So "five fields". Examples: 192.168.510.971.11 10.0.0.0.1 382.201.769.25.133 IPFF addresses are 50-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in Section 2 of [IPFF]). Each field is 10-bits wide, but due to human-memory constraits, values are limited to "999" per field. Why go to the great length of dis-guard perfectly useable bits? Why not up to 1023.1023.1023.1023.1023, as 10-bit fields imply? Bits in IPFF are a bit under-utilized. Well, IP-FF was designed with humans in mind. Limit of three-digits allows for easy readability, comparison, memorization and visualizing network topology in human memory, just like in IPv4, unlike IPv6. This is a small sacrifice of total address range with a huge human benefit. And in modern computing devices are typically represented by 64-bit unsigned integer, pre-padded with 14-bits of zeroes. There are three types of addresses: Unicast: An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Anycast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). Multicast: An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. Like in IPv6, there are no broadcast addresses in IPFF, their function being superseded by multicast addresses. Unlike IPv6, the use of IGMP is optional; That is a system can join a Multicast group, but not send any message about it. In IPFF, all zeros and all ones are legal values for any field, unless specifically excluded. Specifically, prefixes may contain, or end with, zero-valued fields. 2.1. Addressing Model IPFF addresses of all types are assigned to interfaces, not nodes. An IPFF unicast address refers to a single interface. Since each interface belongs to a single node, any of that node's interfaces' unicast addresses may be used as an identifier for the node. A single interface may also have multiple IPFF addresses of any type (unicast, anycast, and multicast), but typically has only one primary unicast address. Currently, IPFF continues the IPv4 model in that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link, one per IP address. 2.2. Text Representation of Addresses There are two conventional forms for representing IPFF addresses as text strings: 1. The preferred form is x.x.x.x.x, where the 'x's are one to three decimal digits. 2. Special case: shortening In order to make writing addresses containing zero fields easier, a special syntax is available to compress the zeros. The use of ".." indicates fields of 10 bits of zeros. For example, the following addresses 0.0.0.0.1 the loopback address 0.0.0.0.0 the unspecified address may be represented as ..1 the loopback address ..0 the unspecified address Note, that this shortened form is allowed only for loopback and unspecified addresses, as a unicast & multicast are unlikely to have too many zeroes to warrant a special case. 2.3. Text Representation of Address Prefixes The text representation of IPFF address prefixes is similar to the way IPv4 address prefixes are written in Classless Inter-Domain Routing (CIDR) notation [CIDR]. An IPFF address prefix is represented by the notation: IPFF-address/prefix-length where IPFF-address is an IPFF address in any of the notations listed in Section 2.2. prefix-length is a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix. 40 is default, if not specified. That means, 4 fields for the network portion, and one field of 10-bits for the hosts. This is an equivalent of an IPv4 subnet mask. Examples: 192.168.510.971.11/30 10.0.0.0.1 (implies /40) 382.201.769.25.133/34 2.4. Address Type Identification The type of an IPFF address is identified by the high-order bits of the address, as follows: Address type Binary prefix IPFF notation Section ------------ ------------- ------------- ------- Unspecified 00...0 (50 bits) ..0/50 2.5.2 Loopback 00...1 (50 bits) ..1/50 2.5.3 Multicast 01100011 000001001 99.9../20 2.7 Unicast (everything else) Anycast addresses are taken from the unicast address spaces (of any scope) and are not syntactically distinguishable from unicast addresses. 2.5. Unicast Addresses IPFF unicast addresses are aggregatable with prefixes of arbitrary bit-length, similar to IPv6 and IPv4 addresses under Classless Inter-Domain Routing. 2.5.1. Private addresses Similarly to IPv4 private addresses defined in RFC-1918, IPFF has several: 10.0.0.0.0 - 10.999.999.999.999 (10.x.x.x.x/10 prefix) 172.16.0.0.0 - 172.31.999.999.999 (172.16-31.x.x.x/16 prefix) 192.168.0.0.0 - 192.168.999.999.999 (192.168.x.x.x/20 prefix) Those were chosen to be visually similar to their IPv4 counterparts, mainly to simplify migration from current IPv4 networks. Those address ranges must not be routed on the Internet, but they can be routed inside an organization. Private addresses are intended for Enterprises that are either not connected to the Internet, or for hosts that are hidden nehind a NAT (Network Address Translation) device, typically a router. An enterprise that decides to use IP addresses out of the address space defined in this document can do so without any coordination with IANA or an Internet registry. The address space can thus be used by many enterprises. Addresses within this private address space will only be unique within the enterprise, or the set of enterprises which choose to cooperate over this space so they may communicate with each other in their own private internet. 2.5.2. AutoIP / link-local unicast addresses In addition, for Auto IP (aka Zeroconf aka Stateless DHCP aka optional link-local addresses), another range was defined: 0.169.254.x.x/30 This address ranges should not be routed on the Internet, and not inside an organization. Those are considered unique only in a layer-2 broadcast domain, link scope, therefore should not pass a router without a network address translation. Because link-local addresses are not required in IPFF, and not recommended, the procedure of getting or generating them is not described in this document. The packet originating from those addresses should have a TTL value of 1. 2.5.3. The Unspecified Address The address 0.0.0.0.0 is called the unspecified address. It must never be assigned to any node. It indicates the absence of an address. One example of its use is in the Source Address field of any IPFF packets sent by an initializing host before it has learned its own address. The unspecified address must not be used as the destination address of IPFF packets or in IPFF Routing headers. An IPFF packet with a source address of unspecified must never be forwarded by an IPFF router. 2.5.4. The Loopback Address The unicast address 0.0.0.0.1/50 is called the loopback address. Can be shortened to ..1 on input. It may be used by a node to send an IPFF packet to itself. It must not be assigned to any physical interface. The loopback address must not be used as the source address in IPFF packets that are sent outside of a single node. An IPFF packet with a destination address of loopback must never be sent outside of a single node and must never be forwarded by an IPFF router. A packet received on an interface with a destination address of loopback must be dropped. 2.5.5. Global Unicast Addresses The can be anything that is not reserved for other purposes. That is from 0.0.0.0.0 up to 999.999.999.999.999 but excluding unspecified, loopback, multicast range, private IPs and auto IPs. Packets received with addresses above "999" in any one field should be dropped. 2.6. Anycast Addresses An IPFF anycast address is an address that is assigned to more than one different node, with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. Anycast addresses are allocated from the unicast address space, using any of the defined unicast address formats. Thus, anycast addresses are syntactically indistinguishable from unicast addresses. The Router's job is to make sense of them, and route traffic to the nearest node. 2.7. Multicast Addresses An IPFF multicast address is an identifier for a group of interfaces (typically on different nodes). An interface may belong to any number of multicast groups. They start with 99.9.x.x.x/20 In IPFF, we have three types of Multicast Addresses: Private Multicast addresses, Link-Local Multicast addresses, and Public Multicast addresses. Link-local Multicast address range defined: 99.9.0.0.x/40 Private Multicast address range defined: 99.9.0.1.x/40 ...and the big different between them is "IGMP". Link-local multicast addresses are logically in-between traditional multicast, that advertises itself by IGMP, and broadcast that does not. It means, that services, that nodes listening on Link-local Multicast addresses *DO NOT* advertise that they have joined Multicast group X, but nodes listening on Private Multicast addresses *DO* advertise via IGMP. Link-local Multicast address listeners also called "silent multicast listeners". "Silent listeners" compared to traditional Multicast: Benefit is two fold: simple IPFF implementations are possible, as IGMP implementation is not needed, and if you want to receive only a few packets, you really don't need to flood whole network by IGMP advertisements. So on the operating system level, a listener is still required join a "Multicast group", but no advertisement is sent. "Silent listeners" compared to traditional broadcasts: ...nodes still get Layer 2 flooding / broadcasts, but using different IP addresses and different layer 2 addresses, nodes can filter unnecessary traffic at layer 2 (by a node's Ethernet controller, for example), instead of by TCP layer. Ethernet examples are part of the [LARA] spec. 2.7.1. Pre-Defined Multicast Addresses The following well-known multicast addresses are pre-defined. Use of these group IDs for any other scope values, with the T flag equal to 0, is not allowed. Reserved Multicast Addresses: 99.9.0.1.1 = DHCP Servers 99.9.0.0.1 = DHCP Clients DHCP clients are "Silent listeners". They can be minimal embedded devices, and don't have to implement the full IGMP protocol. DHCP servers, on the other hand, are using traditional multicast, and must group-subscribe to this address by IGMP advertisements. 2.8. A Node's Required Addresses Only few: Loopback address. 0.0.0.0.1 At least one Unicast address, plus prefix (similar to subnet mask). That's it ! Beyond required addresses, here are some RECOMMENDED addresses: -DNS address -Default Gateway -Backup Default Gateway 2.9. Non-contiguous wildcard masks Some firewall vendors allow for Non-contiguous masks in IPv4, and the same tradition can be kept with IPFF, but only for traffic filtering purposes. Wildcard mask is somewhat similar to the IPv4 subnet mask, but in reverse. 1-bits are for *host portion*, while 0-bits are for *network portion*. A Non-contiguous IPFF wildcard mask may look like: 0.0.1018.517.1023 All connectivity and routing-related decisions must use a prefix notation, and thus be contiguous. NOTE: While quad-digits per field (like .1023) are prohibited from IPFF addresses, they are okay for the purpose of Wildcard masks. 2.10. Not all subnets are born equal Let's take a /45 prefix, for example. It means that I want to divide my 5th field into 32 subnets with 32 hosts each. 10.0.0.0.0/45 subnet will have 32 hosts. (up to .31) 10.0.0.0.32/45 subnet will have 32 hosts. (up to .63) ... But what about the last subnet ? 10.0.0.0.992/45 subnet should have 32 hosts... But it can't ! Why ? Theoretically, it should have up to .1023 but the limit is .999, This implies that some subnets may be not full, or not usable. So this last subnet will have only 8 hosts ! (up to .999) The limit was introduced to conserve *human* memory, which is more precious than computer memory nowadays... So we, humans, need to remember only three digits per field, instead of four. 3. Routing and Invalid Addresses Routing should be done in full 50-bit addresses, but if any field is bigger than 3 decimal digits "999", this traffic is invalid and must be silently dropped. No ICMP message needs to be sent. Access-level routers (those speaking to client-side equipment), power-grid-connected end-nodes (clients & servers) and firewalls MUST validate each field separately, and drop invalid traffic. Mobile devices and embedded devices MAY enforce this rule. Core Routers are not required to check this, for efficiency reasons. Optimization hints: for session-oriented protocols, such as TCP, it should be enforced only during session creation (SYN packet). 4. Acknowledgements The author would like to thank all previous IPv4 and IPv6 developers for their hard work, and benefit for humanity. This document is based is RFC-4291 and RFC-1918. Authors' Contacts Alexey Eromenko Israel Skype: Fenix_NBK_ EMail: al4321@gmail.com Based on the hard work of "Stephen E. Deering" and "Robert M. Hinden", from IPv6 project, as well as all previous TCP/IP developers from DARPA. Alexey INTERNET-DRAFT expiration date: 2016-06-10