Internet DRAFT - draft-eromenko-ipff-lara

draft-eromenko-ipff-lara



INTERNET-DRAFT
"Internet Protocol Five Fields - Link Address Resolution Algorithm", 
Alexey Eromenko, 2016-02-07, 
<draft-eromenko-ipff-lara-03.txt>
expiration date: 2016-08-07

Intended status: Experimental
                                                              A.Eromenko
                                                           February 2016



                    Link Address Resolution Algorithm
                   for Internet Protocol "Five Fields"
                  =====================================
                           Specification Draft

Abstract

   This document describes how-to correlate between IEEE 802.3 Ethernet
   addresses and Internet Protocol "Five Fields" (IP-FF) addresses,
   including unicasts, multicasts and duplicate address detection 
   mechanism, and the procedure to boot-up IPFF stack on Ethernet links.


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."

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. Generating Logical MAC addresses
   3. Duplicate Address Detection (DAD)
   3.1. FastDAD - Unicast Duplicate Address Detection
   3.1.1. FastDAD request example
   3.1.2. FastDAD reply example
   3.1.3. Bonus: Duplicate MAC address detection
   3.2. MultiDAD - Multicast Duplicate Address Detection
   3.2.1. MultiDAD request example
   3.2.2. MultiDAD reply example
   3.3 PowerDAD - Broadcast Duplicate Address Detection
   3.3.1. PowerDAD request example
   3.3.2. PowerDAD reply example
   3.4. SleepyDAD - Passive Duplicate Address Detection
   4. Limitation: What we do not detect ?
   4.1. Other limitation: First Field Overlapping
   4.2. Dot1Q VLANs limitation
   5. Booting IPFF stack
   5.1. Broadcast Advertisement
   6. Dual-Stack operation hints
   7. Private MAC addresses on Ethernet networks
   8. Mapping of Multicast addresses
   9. Theoretical Efficiency vs ARP/NDP
   Authors' Contacts



1. Introduction

   This document describes specification for a resolution between IPFF
   addresses and IEEE 802.3 Ethernet addresses, as well as a Duplicate 
   Address Detection protocol. Other data-link layers may require 
   separate specifications.

   Minimum Prefix:
   The minimum prefix on Ethernet interfaces is /10.

   On Ethernet, instead of resolving a logical IP address to a physical
   MAC address, we simply generate our own logical MAC addresses as a 
   one-way function from logical IP addresses.

   This "trick" can be done because physical MAC addresses are actually
   stored in RAM or a re-writable register in the Ethernet controller 
   driver, and therefore changeable (until the next reboot).



2. Generating Logical MAC addresses

   One-way function to generate MAC address is to put last 40-bits 
   (four fields) of an IPFF address into a logical MAC container, 
   beginning with   0A:xx:xx: xx:xx:xx

   So let's take an IP address like this:
         382.201.769.25.133

   IP:
   2nd Field    - 3rd Field    - 4th field    - 5th field
   00 1100 1001 - 11 0000 0001 - 00 0001 1001 - 00 1000 0101

   Logical MAC address:
   2nd Octet - 3rd Octet - 4th Octet - 5th Octet - 6th Octet

   0011 0010 - 0111 0000 - 0001 0000 - 0110 0100 - 1000 0101 (binary)
   0x 32     - 0x 70     - 0x 10     - 0x 64     - 0x 85     (hexa)

   So our final logical MAC address will look like:
   0A:32:70:10:64:85

   This is a one-way function. You can convert any IPFF address to
   a logical MAC, but not the other way around, which is why minimal
   IP prefix is /10.



3. Duplicate Address Detection (DAD)

   Fast Duplicate Address Detection (FastDAD) means by Unicast frames.
   If a request comes with broadcast layer 2 address, so will reply.

   This technique somewhat similar to Gratuitous ARP, but not exactly.

   ICMP packet:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
 12|                        Source MAC address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 16|     Code      | Reserved  |                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+                                   +
 20|                     Requested IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 24|                                                               |
   +                       IPFF Session ID                         +
 28|                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(bytes)

   IP Fields:
   
   HTL = 1 (Hops-to-Live)
   Source IP Address = Destination IP Address

   ICMP Fields:

   Type: (16-bit)
     (proposed values; to be assigned by IANA)

   16 = DAD request
   17 = DAD reply

   Code: (8-bit)

   0 = FastDAD  (Unicast)
   1 = MultiDAD (Multicast)
   2 = PowerDAD (Broadcast)

      In case of a reply, this code must match a code from the request.

   Source MAC address (48-bit) - Physical MAC of the computer sending
                                 this packet.

   Requested IP address (50-bit) - the IP address a node wants to assign
                                   itself.

   IPFF Session ID (64-bit)    - an additional unique identifier to 
                                 detect duplicate MAC addresses.
                                 Randomly generated value during init.
                                 Does not change until stack reboot.
                                 Unique per host/VRF, not per interface.

   Reserved                    - Initialized to zero on transmission;
                                 ignored by receiver.

3.1. FastDAD - Unicast Duplicate Address Detection

   This is the fastest method, that catches only a subset of the DAD
   problems. It uses Unicast, and is the most CPU and network efficient.

3.1.1. FastDAD request example

   Assume PC-"A" has a MAC address: B8:6B:23:7B:C3:79
   Assume PC-"B" has a MAC address: B8:6B:23:7B:C3:80
   Assume PC-"A" wants to get IP 382.201.769.25.133

   Ethernet layer:
   dst.MAC: 0A:32:70:10:64:85 (Unicast to Logical MAC of target IP;)
                               Derived from 382.201.769.25.133 earlier.
   src.MAC: B8:6B:23:7B:C3:79 (physical MAC of PC-"A")

   IP layer:
   src.IP: 382.201.769.25.133 (same as destination)
   dst.IP: 382.201.769.25.133
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)

   ICMP layer:
   Type: 16 = DAD request
   Code: 0 (FastDAD)
   IP-FF session ID= AAA
   src.MAC: B8:6B:23:7B:C3:79 (same as on Ethernet layer)
   Requested IP: 382.201.769.25.133

3.1.2. FastDAD reply example

   Ethernet layer:
   dst.MAC: B8:6B:23:7B:C3:79 (physical MAC of PC-"A")
   src.MAC: B8:6B:23:7B:C3:80 (physical MAC of PC-"B")
   IP layer:
   src.IP: 382.201.769.25.133 (same as destination)
   dst.IP: 382.201.769.25.133
   ICMP layer:
   Type: 17 = DAD reply
   Code: 0 (FastDAD)
   IP-FF session ID= BBB
   src.MAC: B8:6B:23:7B:C3:80 (same as in Ethernet layer)
   Requested IP: 382.201.769.25.133 (same as in request)

   Duplicate IP detected !
   (no reply = all good)

3.1.3. Bonus: Duplicate MAC address detection

   This scenario can be a result from careless clone-deployment of
   virtual machines.

   If receiving station has the same physical MAC as received DAD 
   request, we compare IPFF session ID. If it is different, we send 
   a reply:

   FDAD reply #2
   Ethernet layer:
   dst.MAC: FF:FF:FF:FF:FF:FF (reply sent to Layer 2 broadcast,
                               to make sure it traverses ALL switches)
   src.MAC: B8:6B:23:7B:C3:79 (physical MAC of PC-"C" & "A")

   IP layer:
   src.IP: 382.201.769.25.133 (same as destination)
   dst.IP: 382.201.769.25.133
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)

   ICMP layer:
   Type: 17 = DAD reply
   Code: 0 (FastDAD, due to request being FastDAD code 0)
   IP-FF session ID= CCC
   src.MAC: B8:6B:23:7B:C3:79  (same as on Ethernet layer)    
   Requested IP: 382.201.769.25.133 (same as in request)

   Duplicate IP & physical MAC detected !
   (no reply = all good)


3.2. MultiDAD - Multicast Duplicate Address Detection

   A Multicats Duplicate Address Detection (MultiDAD) is similar to 
   FastDAD, but using multicast addresses, with least significant 
   10-bits (last field) moved to the Multicast MAC address.

   The request is always sent to 99.9.0.1.x/40; where "x" is the last
   dectet of an IP address we are probing for...
   Reply must be answered to the same address.

   NOTE: This address mapping is somewhat similar to IPv6 
   "Solicited-node Multicast Address".
   In IP-FF this is called "Node Multicast Address".

   It also allows to catch "First Field Overlap" (FFlap),
   problems, things like 10.168.1.1.1 and 192.168.1.1.1
   sitting on the same Broadcast Domain.

   This is the recommended mode, that will catch most problems, at 
   a good performance.

3.2.1. MultiDAD request example

   A classic First Field Overlap problem (FFlap)
   Assume PC-"A" has a MAC address: B8:6B:23:7B:C3:79 and no IP.
   Assume PC-"B" has a MAC address: B8:6B:23:7B:C3:80 and IP 
      192.168.1.2.701
   Assume PC-"A" wants to get IP 10.168.1.2.701

   Ethernet layer:
   dst.MAC: 55:55:00:00:06:BD (Node Multicast address)
   src.MAC: B8:6B:23:7B:C3:79 (physical MAC of PC-"A")

   IP layer:
   src.IP: 0.0.0.0.0      (Unspecified)
   dst.IP: 99.9.0.1.701   (Node Multicast address)
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)


   ICMP layer:
   Type: 16 = DAD request
   Code: 1 (MultiDAD)
   IP-FF session ID= AAA
   src.MAC: B8:6B:23:7B:C3:79 (same as on Ethernet layer)
   Requested IP: 10.168.1.2.701


3.2.2. MultiDAD reply example

   Ethernet layer:
   dst.MAC: 55:55:00:00:06:BD (Node Multicast address)
   src.MAC: B8:6B:23:7B:C3:80 (physical MAC of PC-"B")

   IP layer:
   src.IP: 192.168.1.2.701  (IP of PC-"B")
   dst.IP: 99.9.0.1.701   (Node Multicast address)
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)

   ICMP layer:
   Type: 17 = DAD reply
   Code: 1 (MultiDAD)
   IP-FF session ID= BBB
   src.MAC: B8:6B:23:7B:C3:80   (same as on Ethernet layer)
   Requested IP: 10.168.1.2.701 (same as in request)

   Because the 40-least-significant bits match, a reply MUST be sent.

   First Field Overlap problem detected !
   (no reply = all good)



3.3. PowerDAD - Broadcast Duplicate Address Detection

   A Powerful Duplicate Address Detection (PowerDAD) is similar to 
   MultiDAD, but using broadcast addresses.

   PowerDAD allows to catch even more problems, compared to MultiDAD;
   For example, it may catch a problem of a duplicate physical MAC
   address, even when computers are using two completely different
   IP-FF addresses, which may be a result of cloned virtual machines.

   This mode has CPU performance consequences, and therefore not 
   recommended for general use, except for network debugging.

3.3.1. PowerDAD request example

   A classic First Field Overlap problem (FFlap)
   Assume virtual-PC-"A" has a MAC address: B8:6B:23:7B:C3:79 and no IP.
   Assume virtual-PC-"B" has a MAC address: B8:6B:23:7B:C3:79 and IP 
      192.168.0.0.1; and this is a clone of virtual PC-"A".
   Assume PC-"A" wants to get IP 192.168.0.1.2

   Ethernet layer:
   dst.MAC: FF:FF:FF:FF:FF:FF (Broadcast)
   src.MAC: B8:6B:23:7B:C3:79 (physical MAC of virtual PC-"A")

   IP layer:
   src.IP: 0.0.0.0.0   (Unspecified)
   dst.IP: 99.9.0.0.1  (Broadcast)
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)

   ICMP layer:
   Type: 16 = DAD request
   Code: 2 (PowerDAD)
   IP-FF session ID= AAA
   src.MAC: B8:6B:23:7B:C3:79 (same as on Ethernet layer)
   Requested IP: 10.168.0.1.2


3.3.2. PowerDAD reply example

   Ethernet layer:
   dst.MAC: FF:FF:FF:FF:FF:FF (Broadcast)
   src.MAC: B8:6B:23:7B:C3:79 (physical MAC of virtual PC-"B")

   IP layer:
   src.IP: 192.168.0.0.1  (IP of PC-"B")
   dst.IP: 99.9.0.0.1     (Broadcast)
   HTL = 1,    ToS = 0,   Protocol = 1 (ICMP)

   ICMP layer:
   Type: 17 = DAD reply
   Code: 2 (PowerDAD)
   IP-FF session ID= BBB
   src.MAC: B8:6B:23:7B:C3:79 (same as on Ethernet layer)
   Requested IP: 192.168.0.1.2 (same as in request)

   Since the source MAC address is an exact duplicate, a reply MUST
   be sent.

   Duplicate MAC address detected ! 
   This is despite different IP address, and different Node Multicast 
   address.
   (no reply = all good)


3.4. SleepyDAD - Passive Duplicate Address Detection

   In addition to active probing, passive probing may take place 
   with hints from various protocols, such as TCP and ICMP.

   If a node get multiple packets destined to it, to its logical MAC 
   address, and its IP address, but not originated from it,
   it is a negative hint of a potential duplicate address.
   It should start the procedure of PowerDAD.

   This part is optional.


4. Limitation: What we do not detect ?

   If there is a duplicate (logical or physical) MAC address,
   not running IPFF it will go undetected by this algorithm.

   One idea to address this limitation, is to run IPv4 ARP
   listener as well as IPv6 Neighbor Discovery Advertisement listener,
   in parallel to IPFF, in Multi-stack operation.
   But Multi-stack listener is outside the scope of this spec.

   Additionally, if after IPFF stack is up-n-running, two broadcast 
   domains with duplicate addresses were subsequently joined,
    we can't detect it in real-time.

   Duplicate physical MAC but different IP.
   NOTE: We don't care, since IPFF uses logical MAC addresses for 
   traffic. We do not detect this scenario.


4.1. Other limitation: First Field Overlapping

   Because of one-to-one mapping, you cannot have overlapping the 
   1st field in the same broadcast domain. This is the "FFlap" problem.

   So something like this will fail badly due to logical MAC collision:

   10.168.x.x.x/20  and  192.168.x.x.x/20 networks
   -or-
   10.0.0.0.1 and 11.0.0.0.1

   They will map to the same logical MAC address.

   Connected to the same broadcast domain (read: one switch). 
   You have to be careful and separate such networks by a separate 
   switch, or VLANs, or router ports.
   This can work with IPv4, but was considered a bad practice there.
   Won't work with IP-FF. 
   Just keep this in mind, when designing IP-FF networks.


4.2. Dot1Q VLANs limitation

   A very fundamental limitation of LARA proposal, is that it partially
   merges Layer 2 (Ethernet) and Layer 3 (IP), and one big limitation
   resulting from it is that LARA is incompatible with the industry-
   standard IEEE 802.1q VLANs and IP address overlapping.
   (which can happen due to NAT or IP-VRF reasons)
   Worse yet, there is no way to detect such overlapping, because 
   Duplicate Address Detection (DAD) cannot traverse VLANs.

   Dot1q VLAN Switches have one shared MAC address table, where a 
   possible solution is to have per-VRF MAC address table, plus first
   field (10-bits).
   Similar issue applies to IP-VRF extension.

   Either a redesign of Ethernet VLANs or going to be required, 
   -or- going  back to more traditional methods, such as ARP.
   In it's current form, LARA is incompatible with Ethernet VLANs.

   
5. Booting IPFF stack

   When booting an IPFF stack, it must be put into "tentative mode",
   until DAD procedure is complete.
   Additionally, IPFF stack must Randomly-generate an IPFF Session ID,
    and "remember" it during an entire session,
    as well as its "physical MAC address", to answer DAD requests.

   Changing an IP address, either statically, via DHCP,
   or otherwise requires a new DAD procedure.
   Changing link up/down state also requires a new DAD procedure.

   It is recommended to periodically restart DAD procedure,
   say once every 120-240 minutes. Configurable by OS vendor.
   This partially solves the 2nd limitation.

   What to do when there is a duplicate address ?

   If a duplicate address detected during IPFF stack bootup,
   and address was manually configured,
   it SHOULD be shutdown, and error MUST reported to the user.
   (via log, GUI dialog, console, SNMP, syslog, or otherwise)
   If address was configured via DHCP, a new DHCP request needs
   to be sent after random delay, asking for the next IP address.

   If a duplicate address detected after IPFF stack bootup,
   it MUST be kept running, and error reported to the user.



5.1. Broadcast Advertisement

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  4|                        CRC32 Checksum                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  8|     Type                      |     Code      |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:

     20 = Broadcast advertisement. (will be assigned by IANA)

   Code:

     0

   If a node has re-connected to a broadcast network (like Ethernet),
   using the same IP subnet, it MAY send a broadcast advertising
   itself. This will force all Ethernet switches to learn it's logical
   MAC address, in case it has moved to a different segment (collision 
   domain), so that all nodes can reach it. 
   This is not needed on cold-boot devices.

   Source MAC = (logical MAC, derived from IP)
   Destination MAC = FF:FF:FF:FF:FF:FF (broadcast)

   Source IP (node's IP address)
   Destination IP = 0.0.0.0.0 (unspecified address, since this command
      is directed at Ethernet switches, rather than hosts)



6. Dual-Stack operation hints

   For working with both IPFF and IPv4/v6, the operating system
   may either use "promiscuous mode" of an Ethernet controller,
   to listen to multiple unicast MAC addresses, or move
   IPv4/v6 to a new logical MAC address, used by IPFF.

   If an Ethernet controller supports "standard mode" listening
   to multiple unicast MAC addresses, it should be chosen.



7. Private MAC addresses on Ethernet networks

   According to various sources on the Internet, the
   following MAC address ranges are considered private.
   Also known as "Locally Administered Address Ranges":

   x2-xx-xx-xx-xx-xx
   x6-xx-xx-xx-xx-xx
   xA-xx-xx-xx-xx-xx
   xE-xx-xx-xx-xx-xx

   Additionally all MAC addresses beginning with odd number in the 
   first octet, are Multicast or Broadcast MAC addresses, and are all 
   private.


8. Mapping of Multicast addresses

   Multicasts in IPFF begin with 99.9.x.x.x/20

   Multicast MAC addresses must have first octet number odd.

   MAC addresses in IPFF will get 55:55:xx:xx:xx:xx (32 bits for nodes)
   Only 30 least significant bits will be mapped directly, and first 20
   bits ignored. This is called a "Link Multicast Group"; LMG for short.

   Example:

   99.9.0.0.4 (DHCP clients; our "Silent Multicast Listeners") -- 
   all will get a "Link Multicast Group" MAC address of:

   55:55:00:00:00:04

   Because IGMP advertisement is not used for "Silent listeners",
   smart switches cannot do IGMP snooping, and will have to flood 
   such packets on all ports, like broadcast.

   But a node's Ethernet controller, in "standard mode", can filter
   unnecessary traffic, without interrupting the CPU, gaining 
   efficiency.

9. Theoretical Efficiency vs ARP/NDP

   LARA (Link Address Resolution Algorithm) is much more efficient than
   IPv4 ARP or IPv6 NDP; This is because efficiency of LARA has overhead
   of (O) [source nodes] while ARP/NDP have overhead 
   of (O)^2.  [source-destination pairs]

   O = amount of Objects (nodes) in the Ethernet broadcast domain.
   And the packets sent are due to DAD algorithm, not discovery per-se.

Authors' Contacts

   Alexey Eromenko
   Israel

   Skype: Fenix_NBK_
   EMail: al4321@gmail.com
   Facebook: https://www.facebook.com/technologov

INTERNET-DRAFT
Alexey

expiration date: 2016-08-07