[dhcwg] about v4configuration and co (1)

[Francis Dupont <[e-mail]>]

First I am explaining my comment at the dhc/sunset4 meeting yesterday:
"DHCPv4 is not really over UDP/IP"
What I mean is no genuine IPv4 stack is able to send or receive
a DISCOVER message from a booting device: this message has the
format of an UDP/IPv4/ethernet-like packet but has only the format.

Note this is not true for DHCPv6: constrained DHCPv6 messages
are real link-local multicast messages. This can introduce
anoying limitations but they can be sent or received by any
standard IPv6 stack, when DHCPv4 requires handling of some messages
at the ethernet-like link layer (vs IP network layer).

To come back to v4configuration candidates:

 - first I have no concern against DHCPv6 over DHCPv4 other than it is
  not yet implemented and I am afraid it will not be so easy to
  implement. But it provides better integration, have to obvious
  reason to fail to work, etc, so I agree it is the best solution *on
  the paper*.

 - to extend DHCPv6 is a sure way to mess it so I agree this solution
  must be rejected.

 - DHCPv4 over softwire works well if all nodes already have IPv4
  addresses.  If they have none one enters in difficulties which are
  IMHO the direct consequence of the "DHCPv4 is not really over
  UDP/IP".  So if the requirements include to asignment of IPv4
  addresses to nodes without one (and they should include this) then
  the DHCPv4 over softwire is not a good solution.
  Another point is DHCPv4 over softwire can require a ALG (Application
  Level Gateway) at the server exit point in order to provide the
  IPv6 address (or any topological ID) to the DHCPv4 server.

 - DHCPv4 over IPv6: I know it pretty well as I implemented it
  (note that I am not particularly in favor of it, I am too old
  to fall into this, but it is not a reason to not correct some
  facts about it).
  DHCPv4 over IPv6 has 2 central ideas: first is to give the
  possibility to use an *unmodified* DHCPv4 client (to provide
  this feature is the role of the CRA), second is to give the
  possibility to use a lightly modified DHCPv4 server (to provide
  this feature is the role of the TRA and the CRA6ADDR relay option).

  BTW as the DHCPv4 can't be attached directly to the client link
  "by definition", a relay option is required to give to the server
  the topological position of the client, so the CRA6ADDR option
  can't be avoid and its support is the only required change in
  the DHCPv4 server in the deployment with a TRA case.
  
  Implementing and testing DHCPv4 over IPv6 I found 3 issues:
  * first without care (i.e., check of the link layer address)
  a CRA will relay all DISCOVERs from booting nodes, so with N CRA
  and M booting nodes you get N * M copies. This was fixed in the
  spec with the HCRA / LCRA notion.

  A more anoying issue is what happens when a client renews its
  leased address: it tries first to send a request to the server
  over IPv4 using the server ID. There are two ways to solve this:
  * put a 0.0.0.0 in the server ID but this is forbidden by DHCPv4
   spec, disable server selection and is refused by some clients.
  * put a not-routable address in the server ID: it is compliant,
   still provide server selection and works because clients will
   fall back to broadcast DISCOVER, i.e., it just de-optimizes
   the renewal mechanism.
  Note one must not allow the renew message to reach the DHCPv4
  server because the topological info added by a relay is required.

 The last issue was from the fully incorrect/... support of
 SO_REUSEADDR by Linux which makes impossible to run some
 DHCPv4 servers on the same node than a DHCPv4 over IPv6 client
 and CRA.

 Note the last 2 points are direct consequences of the idea to
 reuse DHCPv4 clients, with other words they are drawbacks from
 the DHCPv4 over IPv6 simplicity.

 To finish it is not hard to modify a DHCPv4+DHCPv6 server code
 to handle DHCPv4 over IPv6, i.e., DHCPv4 messages over IPv6
 or even both over IPv6 and IPv4. The idea is to plug the IPv6
 I/O subsystem to the DHCPv6 handler. IMHO it should not be
 significanly different (i.e., harder / easier) to support
 DHCPv6 over DHCPv4 (note this is for the server code).

Regards

[e-mail]

PS for moderator: I tried to submit this first from a wrong address
so I canceled it and you should not have to do something. Sorry
for my mistake.