





Network Working Group                                        A. Eromenko
Category: Proposed Standard                                December 2015


                  IP Version 5 Addressing Architecture
             aka Internet Protocol "Five Fields" (IP-FF; draft)

Copyright Notice

   Copyright (C) Alexey Eromenko (2015), based on the work of 
   The Internet Society (2006).

Abstract

   This specification defines the addressing architecture of the IP
   Version 5 (IPv5) protocol.  The document includes the IPv5 addressing
   model, text representations of IPv5 addresses, definition of IPv5
   unicast addresses, anycast addresses, and multicast addresses.

Table of Contents

   1. Introduction ....................................................2
   2. IPv5 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...................................
   5. Acknowledgements ...............................................18
   6. References .....................................................18
      6.1. Normative References ......................................18
      6.2. Informative References ....................................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 IPv5 addresses (unicast, anycast, and multicast).

2.  IPv5 Addressing

   The main benefit of IPv5, 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

   IPv5 addresses are 50-bit identifiers for interfaces and sets of
   interfaces (where "interface" is as defined in Section 2 of [IPv5]).
   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 IPv5 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 IPv5, 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 IPv5, 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

   IPv5 addresses of all types are assigned to interfaces, not nodes.
   An IPv5 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 IPv5 addresses of any type
   (unicast, anycast, and multicast), but typically has only one
   primary unicast address.

   Currently, IPv5 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 IPv5 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 IPv5 address prefixes is similar to the
   way IPv4 address prefixes are written in Classless Inter-Domain
   Routing (CIDR) notation [CIDR].  An IPv5 address prefix is
   represented by the notation:

      ipv5-address/prefix-length

   where

      ipv5-address    is an IPv5 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 IPv5 address is identified by the high-order bits of
   the address, as follows:

      Address type         Binary prefix        IPv5 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

   IPv5 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

   Similar to IPv4 private addresses defined in RFC1918, IPv5 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.

   Plus there is a private Multicast address range defined:

       99.9.0.0.x/40

2.5.2. AutoIP / link-local 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 IPv5, 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 IPv5 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 IPv5 packets or in IPv5 Routing headers.  An IPv5 packet with a
   source address of unspecified must never be forwarded by an IPv5
   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 IPv5 packet to itself.  It must
   not be assigned to any physical interface.

   The loopback address must not be used as the source address in IPv5
   packets that are sent outside of a single node.  An IPv5 packet with
   a destination address of loopback must never be sent outside of a
   single node and must never be forwarded by an IPv5 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 IPv5 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 IPv5 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

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.x.x.x/20
                                   99.9.0.0.1 = DHCP Servers
                                   99.9.0.0.2 = DHCP Clients (listening)

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 IPv5, 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 IPv5 wildcard mask may look like: 0.517.1023.0.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
   IPv5 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 placed at home or those speaking to 
   client-side equipment), end-nodes (clients & servers) and firewalls 
   MUST validate each field separately, and drop invalid traffic.
   Core Routers are not required to check this, for efficiency reasons.

5.  Acknowledgements

   The author would like to thank all previous IPv4 and IPv6 developers for
   their hard work, and benefit for humanity.

6.  References

Authors' Contacts

   Alexey Eromneko
   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.   

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

