INTERNET-DRAFT "Internet Protocol Five Fields - Dynamic Host Configuration Protocol", Alexey Eromenko, 2015-12-28 expiration date: 2016-06-28 Intended status: Standards Track Intended status: Standards Track A.Eromenko December 2015 Dynamic Host Configuration Protocol ------------------------------------- Required modifications for Internet Protocol "Five Fields" PROTOCOL SPECIFICATION draft Abstract This document describes that changes needed in 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 DHCPv5 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 DHCPv5 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 | yiaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 16| 'your' (client) IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 20| flags | siaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 24| IP address of next server to use in bootstrap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 28| Reserved | giaddr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 32| Relay agent IP address | +---------------------------------------------------------------+ | | | chaddr (16-bytes) | | Client hardware address | | | +---------------------------------------------------------------+ | | | servername (128-bytes) | +---------------------------------------------------------------+ | | | bootfile (128-bytes) | +---------------------------------------------------------------+ | | | options (variable) | +---------------------------------------------------------------+ (bytes) Figure 1: Format of a DHCP message 2. Changes from DHCPv4, as defined in RFC-2131 FIELD BITS DESCRIPTION ----- ------ ----------- ciaddr Client IP address; only filled in if client is in BOUND, RENEW or REBINDING state and can respond to ARP requests. 'ciaddr', which was present in DHCPv4, is no longer here, and is replaced by "Source IP address" of an incoming DHCP request. It should be retrieved from the IP packet. Version 4 Versioning was added to simplify future evolution. = 1 Hops 4 Hops field shrikned from 8 bits to 4 bits. servername 128 Bytes. It was extended from 64 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 Booting IP-FF stack is covered in Link Address Resolution Algorithm "LARA" specification. In general case, with DHCP it should be 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.1.1 The destination multicast address for DHCP clients is 99.9.0.0.1 4. Throttling / Delayed replies on High usage 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 SHOULD be implemented in "Corporate" DHCP servers, but not required for "Home" segment products. 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: 2016-06-28