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

From: Francis Dupont <[email-masked]>
Date: Thu, 01 Aug 2013 10:11:50 +0200

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

[email-masked]

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.

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2013 13:21:56 +0200

Francis,

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

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

> 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

---

From: <[email-masked]>
Date: Tue, 6 Aug 2013 15:19:29 +0200

Hi Ole,

Comments inline below.

Cheers,
Ian

>- coupling IPv6 and IPv4 provisioning together is a bad idea

[ina] Agreed

>  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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2013 15:28:20 +0200

Ian,

> Putting it over the IPv4 data path is going to make this a pretty softwire

it would be dependent on a broadcast capable link-layer supporting IPv4,
that isn't softwire specific as such.

you aren't suggesting that there is a need to provision IPv4 on a node that has no way to send IPv4 packets?

cheers,
Ole

---

From: Ian Farrer <[email-masked]>
Date: Tue, 6 Aug 2013 16:09:00 +0200

Hi Ole,

Inline

Cheers,
Ian

> that isn't softwire specific as such.

[ian] Couple of points arising from this:

1, This also describes a basic Ethernet interface. The behaviour for an Ethernet based DHCP client will be different (regular port 68 communication, can't use shared IPv4 addresses). So, there needs to be DHCP client logic to work out the right behaviour for the particular properties of the link it's running on.
2, Are translation (4-6, such as MAP-T) broadcast capable (I don't know the answer to this one, I've really never considered putting broadcasts through a NAT)?

> you aren't suggesting that there is a need to provision IPv4 on a node that has no way to send IPv4 packets?

[ian] Not at all. I believe the concept of separating data and configuration planes is well understood:-)

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Aug 2013 16:36:43 +0200

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

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

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

>  given that a softwire is a p2p link, it does support broadcast (and

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

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

---

From: Francis Dupont <[email-masked]>
Date: Mon, 12 Aug 2013 16:42:37 +0200

>  approach must not be limited to only supporting softwire configuration."

=> DHCPv4 (and unfortunately DHCPv6 too) has a lot of strong constraints
on its usage environment because it has to work from no knowledge at all
(first no IP address...). My concern with the "information mode" of
DHCPv4 is these constraints remain. I believe you have the same concern
but you use a very different wording for the same result: "a suitable
approach must not be limited to only supporting softwire configuration".

Thanks

---

From: Ole Troan <[email-masked]>
Date: Tue, 13 Aug 2013 10:19:38 +0200

Francis,

> you'll have nobody to blame because the case is not described in

my favourite implementation does indeed use the IP stack.
that IP stack supports sending packets to the broadcast address from the unspecified address.
no magic with regards to that. my favourite implementation also give direct access from
applications to the link-layer for that matter. ;-)
I don't understand what you mean by "not described in the specs". 

> support (and specifications if you want interoperability).

sounds to me like you are describing problems that certain implementations would have with
implementing this. I gave existence proof of an implementation that doesn't.

> the slide about real (vs info only) DHCPv4 over softwire slide).

you state that "IPv4 address provisioning should not run over the IPv4 data path".
what makes a softwire different from an Ethernet?
it supports broadcast, and the restriction that the first-hop router must be a DHCP relay or server
applies, but what makes this link-type so different that we need to invent new provisioning mechanics for it?

when we designed e.g. 6rd and MAP that was certainly not the intention.

cheers,
Ole

---

From: Francis Dupont <[email-masked]>
Date: Thu, 15 Aug 2013 15:54:22 +0200

In your previous mail you wrote:

>  my favourite implementation does indeed use the IP stack.  that IP
>  stack supports sending packets to the broadcast address from the
>  unspecified address.

=> this is really not standard: usually when the source address
is left unspecified the kernel replaces it by one of the addresses
of the host...

>  no magic with regards to that. my favourite implementation also give
>  direct access from applications to the link-layer for that matter. ;-)

=> this is common to all OSs, unfortunately without a standardized way.

>  I don't understand what you mean by "not described in the specs".

=> there is no "DHCP over foo" for a generic foo, even for a generic
tunnel. In fact DHCP (and BOOTP) has to be specialized for each
link (hardware in specs) layer, so have to be described in some specs.

>  you state that "IPv4 address provisioning should not run over the IPv4

=> yes, it is my opinion and it seems this opinion is shared by
many other persons in the list.

>  what makes a softwire different from an Ethernet?

=> Ethernet is a hardware link layer

>  what makes this link-type so different that we need to
>  invent new provisioning mechanics for it?

=> separation of control and data planes, or with other words
simpler bootstrap/setup without a critical element (the source
IPv4 address) unknown a priori.

>  when we designed e.g. 6rd and MAP that was certainly not the intention.

=> if we have today this discussion it is because the problem was not
addressed from the beginning in the design.

Regards