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

[<[e-mail]>]

Hi Ole,

Comments inline below.

Cheers,
Ian


On 06/08/2013 13:21, "Ole Troan" <[e-mail]> wrote:

>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

[ina] Agreed

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


[ian] In the introduction of the v4config draft, it says:
"Although softwire mechanisms are currently the only use-case for DHCP
based configuration of IPv4 parameters in IPv6 only networks, a suitable
approach must not be limited to only supporting softwire configuration."

Putting it over the IPv4 data path is going to make this a pretty softwire
dependant solution.



>
>cheers,
>Ole
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dhcwg