Internet DRAFT - draft-eromenko-ipff-dhcp
draft-eromenko-ipff-dhcp
INTERNET-DRAFT
"Internet Protocol Five Fields - Dynamic Host Configuration Protocol",
Alexey Eromenko, 2016-09-29,
<draft-eromenko-ipff-dhcp-02.txt>
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
