idnits 2.17.1 draft-eromenko-ipff-arp-01.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 227 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 14 instances of lines with control characters in the document. ** 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 155: '...ally, IPFF stack SHOULD Randomly-gener...' RFC 2119 keyword, line 167: '... it SHOULD be shutdown, and error MU...' RFC 2119 keyword, line 173: '... it MUST be kept running, and error ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2017-03-29) is 2586 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? 'RFC-826' on line 207 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 2 "Internet Protocol Five Fields - Address Resolution Protocol", 3 Alexey Eromenko, 2016-09-29, 4 5 expiration date: 2017-03-29 7 Intended status: Standards Track 9 A.Eromenko 10 September 2016 12 Address Resolution Protocol 13 for Internet Protocol version 5 14 on Ethernet Networks 15 =================================== 16 (aka ARP-FF for IP "Five Fields") 18 Abstract 20 Address Resolution Protocol in IPv5 is basically the same as in IPv4, 21 and it is intended to resolve Data Link Layer Ethernet addresses to 22 Network Layer IP-FF addresses, in addition to Duplicate Address 23 Detection (DAD), includes optional duplicate MAC address detection. 24 This spec was written for IEEE 802.3 Ethernet links or compatible. 25 Separate specifications may be required for other link types. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. ARPv5 header 60 2. ARP Replies 61 3. Booting IPFF stack 62 4. Mapping of Multicast addresses 63 Acknowledgments 64 Authors' Contacts 66 1. ARPv5 header 68 0 1 2 3 69 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 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 4| Hardware Type = 1 (Ethernet) | Protocol Type = 0x9500 (IPFF) | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 8| H.Len = 6 | P.Len = 14 | Operation | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 12| Sender Hardware Address | 76 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 16| | | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 79 20| Sender IP-FF Address | 80 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 24| | | 82 +-+-+ + 83 28| Sender IP-FF Session ID (62-bit) | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 32| Target Hardware Address | 86 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 36| | | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 89 40| Target IP-FF Address | 90 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 91 44| | | 92 +-+-+ + 93 48| Reserved (62-bit) | 94 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 95 (bytes) 97 16-bit: (ar$hrd) Hardware address space (e.g., Ethernet, 98 Packet Radio Net.) 99 16-bit: (ar$pro) Protocol address space. For IP-FF over Ethernet 100 hardware, this equals to Ethertype of IP-FF. 102 (0x9500 for experimental IP-FF, TBD later) 104 8-bit: (ar$hln) Hardware address length, in bytes. = 6 bytes. 105 (for Ethernet MAC) 106 8-bit: (ar$pln) Protocol address length, in bytes. = 14 bytes. 107 IP-FF address has 50-bits, 108 plus few bytes for IPFF session ID. 110 16-bit: (ar$op) opcode (ares_op$REQUEST | ares_op$REPLY) 112 nbytes: (ar$sha) Hardware address of sender of this 113 packet, n from the ar$hln field. 115 50-bit: (ar$spa) Protocol address of sender of this 116 packet, m from the ar$pln field. 117 62-bit: (ar$spa.ext) IPFF session ID. An additional unique 118 identifier to detect a running IP-FF session. 120 Protocol address and IPFF session ID, together, 121 form a 14-byte (112 bit) ARP SPA field. 123 nbytes: (ar$tha) Hardware address of target of this 124 packet (if known). 125 50-bit: (ar$tpa) Protocol address of target, post-padded by a 126 62-bit "reserved" field. 128 "IPFF session ID" -- a new element, not envisioned in the original 129 ARP specification, logically extends the "logical protocol address" 130 field with more bits. 132 It is designed to detect duplicate MAC addresses, which can be 133 a result from careless clone-deployment of virtual machines, 134 along with copied virtual MAC addresses. 136 Randomly generated value during stack init. 137 Does not change until stack reboot. Unique per host/VRF, not per 138 interface. 140 If this field is set to zero, it is ignored, 141 and duplicate MAC address detection is not performed. 143 2. ARP Replies 145 Reply are recommended to be sent as Broadcast, as it improves DAD 146 ability to detect duplicates, and also allows nodes to learn 147 neighbor's MAC addresses much faster, to get a full mesh, you will 148 have an overhead of (O)*2 instead of (O)^2 when using unicast, 149 at a cost of slightly more processor usage, but less network usage. 151 3. Booting IPFF stack 153 When booting an IPFF stack, it must be put into "tentative mode", 154 until DAD procedure is complete, via Gratuitous ARP. 155 Additionally, IPFF stack SHOULD Randomly-generate an IPFF Session ID, 156 and "remember" it during an entire session, 157 as well as its "physical MAC address", to answer DAD requests. 159 Changing an IP address, either statically, or dynamically via DHCP, 160 or otherwise requires a new DAD procedure. 161 Changing link up/down state also requires a new DAD procedure. 163 What to do when there is a duplicate address ? 165 If a duplicate address detected during IPFF stack bootup, 166 and address was manually configured, 167 it SHOULD be shutdown, and error MUST reported to the user. 168 (via log, syslog, GUI dialog, console, SNMP, or otherwise) 169 If address was configured via DHCP, a new DHCP request needs 170 to be sent after random delay, asking for the next IP address. 172 If a duplicate address detected after IPFF stack boot completed, 173 it MUST be kept running, and error reported to the user. 175 4. Mapping of Multicast addresses 177 Silent Multicasts in IPFF begin with 99.9.x.x.x/20 178 Traditional Multicasts in IPFF begin with 99.8.x.x.x/20 180 Multicast MAC addresses must have first octet number odd. 182 MAC addresses in IPFF will get 99:09:xx:xx:xx:xx (32 bits for nodes), 183 for Silent Multicasts and 99:08:xx:xx:xx:xx for traditional 184 Multicast addresses. 186 Only 30 least significant bits will be mapped directly, and first 20 187 bits ignored. This is called a "Link Multicast Group"; LMG for short. 189 Example: 191 99.9.0.0.4 (DHCP clients; our "Silent Multicast Listeners") -- 192 all will get a "Link Multicast Group" MAC address of: 194 99:59:00:00:00:04 196 Because IGMP advertisement is not used for "Silent listeners", 197 smart switches cannot do IGMP snooping, and will have to flood 198 such packets on all ports, like broadcast. 200 But a node's Ethernet controller, in "standard mode", can filter 201 unnecessary traffic, without interrupting the CPU, gaining 202 efficiency. 204 Acknowledgments 206 Based on the hard work of "David C. Plummer", whom wrote the 207 original specification of ARP, as defined in [RFC-826] 209 Authors' Contacts 211 Alexey Eromenko 212 Israel 214 Skype: Fenix_NBK_ 215 EMail: al4321@gmail.com 216 Facebook: https://www.facebook.com/technologov 218 INTERNET-DRAFT 219 Alexey 220 expiration date: 2017-03-29