INTERNET-DRAFT "Internet Protocol Five Fields - Dynamic Host Configuration Protocol", Alexey Eromenko, 2016-09-29, expiration date: 2017-03-29 Intended status: Standards Track A.Eromenko September 2016 Dynamic Host Configuration Protocol ------------------------------------- Required modifications for Internet Protocol "Five Fields" PROTOCOL SPECIFICATION draft Abstract This document describes the changes needed from DHCPv4, as defined in RFC-2131, to bring DHCP to IP-FF. 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. Introduction DHCP in IPv4 works remarkably well, and so a good idea is to keep it almost unchanged in IP-FF. Instead of publishing a full RFC, I focus only on changes required from DHCPv4. Table of Contents 1. Format of a DHCP-FF message 2. Changes from DHCPv4, as defined in RFC-2131 3. Booting IP-FF via DHCP 4. Throttling / Delayed replies on High usage 1. Format of a DHCP-FF message 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|Version| Hops | op | htype | hlen | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8| Transaction ID - xid (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 12| secs | ciaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| client IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| flags | yiaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24| 'your' (client) IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28| Reserved | siaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32| IP address of next server to use in bootstrap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 36| Reserved | giaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 40| Relay agent IP address | +---------------------------------------------------------------+ | | | chaddr (16-bytes) | | Client hardware address | | | +---------------------------------------------------------------+ | | | servername (up to 128-bytes) | +---------------------------------------------------------------+ | | | bootfile (up to 255-bytes) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+ (bytes) Figure 1: Format of a DHCP message 2. Changes from DHCPv4, as defined in RFC-2131 FIELD BITS DESCRIPTION ----- ------ ----------- Version 4 Versioning was added to simplify future evolution. = 1 Hops 4 Hops field shrinked from 8 bits to 4 bits. (if you design a network with a DHCP server over 15 hops away from your clients, you're doing it wrong.) servername 128 Bytes. It was extended from 64 bytes, mainly for Unicode compatibility reasons. A single Unicode character can take 2-3 bytes. file 255 Bytes. It was extended from 128 bytes, mainly for Unicode compatibility reasons. A single Unicode character can take 2-3 bytes. 'Seconds' and 'flags' fields were shrinked from 16-bits to 14-bits. All address fields were extended to 50-bits; forced change. 3. Booting IP-FF via DHCP In general case, booting IP-FF via DHCP is similar to IPv4. That is using an unspecified IP-FF address as source (0.0.0.0.0) and a physical MAC address (on Ethernet) or other Data-Link Layer address. The destination multicast address for DHCP servers is 99.9.0.0.3 The destination multicast address for DHCP clients is 99.9.0.0.4 4. Throttling / Delayed replies on High usage (recommendation) If a DHCP server is also the default gateway, it MAY artificially *delay* giving IP-FF addresses, if CPU or network usage is high, allowing for another DHCP server to answer DHCP, and allowing them becoming default gateways, providing a per-node load-balancing (as opposed to per-session or per-packet load-balancing). Reasonable value is 10 ms delay per 1% CPU or (WAN/external) network bandwidth usage, with delays starting only after 25% usage. This feature MAY be implemented in quality "Enterprise-grade" DHCP servers, but not required. Acknowledgments Based on the hard work of "Ralph Droms", DHCP [RFC-2131]. Author Contacts Alexey Eromenko Israel Skype: Fenix_NBK_ EMail: al4321@gmail.com Facebook: https://www.facebook.com/technologov INTERNET-DRAFT Alexey expiration date: 2017-03-29