INTERNET-DRAFT "Internet Protocol Five Fields - Link Address Resolution Algorithm", Alexey Eromenko, 2016-01-02, expiration date: 2016-07-02 Intended status: Standards Track A.Eromenko January 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: FastDAD and PowerDAD 3.1.1. Fast Duplicate Address Detection Example 3.1.2. FastDAD request example 3.1.3. FastDAD reply example 3.1.4. Bonus: Duplicate MAC address detection 3.2.1. PowerDAD - Broadcast Duplicate Address Detection 3.2.2. Powerful Duplicate Address Detection Example 3.2.3. PowerDAD request example 3.2.4. PowerDAD reply example 3.3. SleepyDAD - Passive Duplicate Address Detection 4. Limitation: What we do not detect ? 4.1. Other limitation: First Field Overlapping 5. Booting IPFF stack 5.1. Broadcast Advertisement 6. Dual-Stack operation hints 7. Private MAC addresses 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: FastDAD and PowerDAD 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| Reserved | | +-+-+-+-+-+-+-+-+-+-+-Requested IP address + 20| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 = FastDAD request 17 = FastDAD reply 18 = PowerDAD request 19 = PowerDAD reply Source MAC address (48-bit) - Physical MAC of the computer sending this packet. Reserved (14-bit) - Initialized to zero on transmission; ignored by receiver. 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. 3.1.1 Fast Duplicate Address Detection Example 3.1.2. 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 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.3. 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 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.4. 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 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 PowerDAD - Broadcast Duplicate Address Detection A Power Duplicate Address Detection (PowerDAD) is similar to FastDAD, but using broadcast addresses. PowerDAD allows to catch more problems; For example, two Ethernet segments that were subsequently united to one, and switch A knows of his address of PC-A, which if a duplicate IP of PC-B. It also allows to catch "First Field Overlap" (FFlap), problems, things like 10.168.x.x.x/20 and 192.168.x.x.x/20 sitting on the same Broadcast Domain. 3.2.1 Powerful Duplicate Address Detection Example 3.2.2. PowerDAD 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.0.0.1 Assume PC-"A" wants to get IP 10.168.0.0.1 Ethernet layer: dst.MAC: FF:FF:FF:FF:FF:FF (Broadcast) 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.0.1 (Broadcast) HTL = 1, ToS = 0, Protocol = 1 (ICMP) ICMP layer: Type: 18 = PowerDAD request IP-FF session ID= AAA src.MAC: B8:6B:23:7B:C3:79 (same as on Ethernet layer) Requested IP: 10.168.0.0.1 3.2.3. PowerDAD reply example Ethernet layer: dst.MAC: FF:FF:FF:FF:FF:FF (Broadcast) src.MAC: B8:6B:23:7B:C3:80 (physical MAC of 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: 19 = PowerDAD reply IP-FF session ID= BBB src.MAC: B8:6B:23:7B:C3:80 (same as on Ethernet layer) Requested IP: 10.168.0.0.1 (same as in request) First Field Overlap problem detected ! (no reply = all good) Design note: Broadcast Layer 2 reply to solve the duplicate MAC address problem. 3.3. SleepyDAD - Passive Duplicate Address Detection In addition to active probing, passive probing should 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. 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. 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 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 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) So those 30 bits will be mapped directly, and first 20 bites 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 While typically ARP or NDP may require (O)*O amount of requests to fill a mesh network, in case of LARA, it is just (O). O = amount of Objects. (nodes) 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-07-02