Re: [v6ops] Please review the No IPv4 draft

[Lorenzo Colitti <[e-mail]>]

Ok. So:

   1. As regards impact to the client - "don't waste your resources sending
   DHCPv4 requests, there's never going to be a DHCPv4 server here", then:
   what's the advantage to the client above doing exponential backoff with one
   packet every 2 minutes / half hour / 2 hours? True, clients don't do
   exponential backoff today, but they will have to be modified anyway for
   this option to work.
   2. As regards impact to the infrastructure: on wifi,
   infrastructure-to-client broadcasts are expensive, but
   client-to-infrastructure broadcasts are effectively unicast. So just
   configuring the AP to drop the packets will do what you want. As regards to
   low-power clients, see #1.

Don't get me wrong - I don't think this is harmful (modulo security
considerations, of course). I just don't think it's a particularly good use
of our time.

If we do do this, on the face of it it would seem that from the host's
perspective it would be better to have this information in DHCPv4 than in
DHCPv6.

Cheers,
Lorenzo


On Tue, Apr 15, 2014 at 1:57 PM, Owen DeLong <[e-mail]> wrote:

>
> On Apr 14, 2014, at 9:20 PM, Lorenzo Colitti <[e-mail]> wrote:
>
> On Mon, Apr 14, 2014 at 11:50 PM, Simon Perreault <
> [e-mail]> wrote:
>
>> In a nutshell, it defines DHCPv6 and RA options indicating to the host
>> that IPv4 is not available. Reviews from operations-minded people in
>> V6OPS would be of tremendous help.
>>
>
> I don't see a strong use case for this. It seems to me that the two
> scenarios in the introduction can be solved by simply configuring the
> DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests.
>
> Am I missing something?
>
>
> I believe the purpose is to get the DHC4 client to stop asking (broadcast
> DHCP4 requests) on networks where repeated garbage packets are less than
> desirable (low power applications, wifi, etc.)
>
> Owen
>
>