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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  > 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"?

=> I believe I explained what I mean by this statement?

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

=> did you check your favourite implementation is really using the
IP stack? Usually DHCPv4 uses a link-layer access like BPF so relies
on the correct support in the link-layer for this specific usage
(so it can work with one implementation but not the other, if
you are unlucky the client and the server won't interoperate, and
you'll have nobody to blame because the case is not described in
the specs...).

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

=> usually the issue with DHCPv4 and encapsulation is not the packet
format (there is a straightforward way for it) but the sanity checks
at the other (here DHCPv4 server) side: how the set the expected source
address without a little idea of what it is?
Note this doesn't make impossible to work, just it requires specific
support (and specifications if you want interoperability).

>  > 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 believe you mean provisioning at the server side (note no
supported solution requires such a coupling).

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

=> the problem is sbout the IPv4 provisioning: if it includes IPv4
address provisioning it should not run over the IPv4 data path.
BTW the I-D is not enough clear about this point to be a critical
requirement or not... (and I raised this concern in my review before
the slide about real (vs info only) DHCPv4 over softwire slide).

Thanks

[e-mail]