Re: [dhcwg] about v4configuration and co (1)

[Ole Troan <[e-mail]>]

Francis,

> 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.

can you explain what you mean by "DHCPv4 is not really over UDP/IP"?

> 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.

I tested DHCPv4 over a softwire with my favourite implementation and that worked out of the box.
DHCPv4 in that it uses broadcast requires a link-layer that supports broadcast.
given that a softwire is a p2p link, it does support broadcast (and multicast).

> - 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).

just to make my own views clear:
- coupling IPv6 and IPv4 provisioning together is a bad idea
- I don't think requiring IPv4 specific configuration information on a softwire is necessary,
  if you really have to do it I'd prefer for the IPv4 provisioning protocol to
  run over the IPv4 data path (aka the softwire). and the same solution could
  be used for Public 4over6, LW46, MAP, L2TP...

cheers,
Ole