idnits 2.17.1 draft-eromenko-ipff-dhcp-02.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 193 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 145: '...er is also the default gateway, it MAY...' RFC 2119 keyword, line 155: '... This feature MAY be implemented in ...' 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-2131' on line 160 looks like a reference Summary: 5 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 - Dynamic Host Configuration 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 Dynamic Host Configuration Protocol 13 ------------------------------------- 14 Required modifications for 15 Internet Protocol "Five Fields" 16 PROTOCOL SPECIFICATION draft 18 Abstract 20 This document describes the changes needed from DHCPv4, as defined in 21 RFC-2131, to bring DHCP to IP-FF. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 Copyright Notice 40 Copyright (c) 2015 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Introduction 55 DHCP in IPv4 works remarkably well, and so a good idea is to keep it 56 almost unchanged in IP-FF. Instead of publishing a full RFC, I focus 57 only on changes required from DHCPv4. 59 Table of Contents 61 1. Format of a DHCP-FF message 62 2. Changes from DHCPv4, as defined in RFC-2131 63 3. Booting IP-FF via DHCP 64 4. Throttling / Delayed replies on High usage 66 1. Format of a DHCP-FF message 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|Version| Hops | op | htype | hlen | 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 8| Transaction ID - xid (4) | 74 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 75 12| secs | ciaddr | 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 77 16| client IP address | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 20| flags | yiaddr | 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 81 24| 'your' (client) IP address | 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 28| Reserved | siaddr | 84 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 85 32| IP address of next server to use in bootstrap | 86 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 87 36| Reserved | giaddr | 88 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 89 40| Relay agent IP address | 90 +---------------------------------------------------------------+ 91 | | 92 | chaddr (16-bytes) | 93 | Client hardware address | 94 | | 95 +---------------------------------------------------------------+ 96 | | 97 | servername (up to 128-bytes) | 98 +---------------------------------------------------------------+ 99 | | 100 | bootfile (up to 255-bytes) | 101 +---------------------------------------------------------------+ 102 | | 103 | options (variable) | 104 +---------------------------------------------------------------+ 105 (bytes) 107 Figure 1: Format of a DHCP message 109 2. Changes from DHCPv4, as defined in RFC-2131 111 FIELD BITS DESCRIPTION 112 ----- ------ ----------- 114 Version 4 Versioning was added to simplify future evolution. 115 = 1 117 Hops 4 Hops field shrinked from 8 bits to 4 bits. 118 (if you design a network with a DHCP server over 15 hops 119 away from your clients, you're doing it wrong.) 121 servername 128 Bytes. It was extended from 64 bytes, mainly for 122 Unicode compatibility reasons. 123 A single Unicode character can take 2-3 bytes. 125 file 255 Bytes. It was extended from 128 bytes, mainly for 126 Unicode compatibility reasons. 127 A single Unicode character can take 2-3 bytes. 129 'Seconds' and 'flags' fields were shrinked from 16-bits to 14-bits. 131 All address fields were extended to 50-bits; forced change. 133 3. Booting IP-FF via DHCP 135 In general case, booting IP-FF via DHCP is similar to IPv4. 136 That is using an unspecified IP-FF address as source (0.0.0.0.0) and 137 a physical MAC address (on Ethernet) or other Data-Link Layer 138 address. 140 The destination multicast address for DHCP servers is 99.9.0.0.3 141 The destination multicast address for DHCP clients is 99.9.0.0.4 143 4. Throttling / Delayed replies on High usage (recommendation) 145 If a DHCP server is also the default gateway, it MAY 146 artificially *delay* giving IP-FF addresses, if CPU or network 147 usage is high, allowing for another DHCP server to answer DHCP, 148 and allowing them becoming default gateways, providing a per-node 149 load-balancing (as opposed to per-session or per-packet 150 load-balancing). 152 Reasonable value is 10 ms delay per 1% CPU or (WAN/external) network 153 bandwidth usage, with delays starting only after 25% usage. 155 This feature MAY be implemented in quality "Enterprise-grade" DHCP 156 servers, but not required. 158 Acknowledgments 160 Based on the hard work of "Ralph Droms", DHCP [RFC-2131]. 162 Author Contacts 164 Alexey Eromenko 165 Israel 167 Skype: Fenix_NBK_ 168 EMail: al4321@gmail.com 169 Facebook: https://www.facebook.com/technologov 171 INTERNET-DRAFT 172 Alexey 173 expiration date: 2017-03-29