[Dnsmasq-discuss] rfc3527 support

[Simon Kelley]

Takayuki Kaiso wrote:
> Hi Simon
> 
>  Thank you so much for the comment, your comments are so helpful.
> 
> (1) thanks to new "fallback" parameter, it made my update easy.
>     now dnsmasq-2.58test6 fills in Server Identifier correctly as I
> reported in my last mail.
> 
> (2) regarding siaddr,  I will take the following approach by you.
>> Add fallback to the arguments list of do_options() (and all the places
>> it gets called from) and then change the siaddr code in do_options to be
>>
>> if (context && context->local.s_addr != 0)
>>     mess->siaddr = context->local;
>> else
>>     mess->siaddr = fallback;
>   BTW,  my iPod is not netbooting, and so I might need to confirm if
> siaddr is
>       really necessary, but it seems the iOS seems so picky for me and
>       want to fill this value.
> 
> (3)  regarding the "fallback" solution, let me ask one question.
> 
>    below shows the snippet from do_options() in rfc2131.c, and I guess
>    you add these codes for default scenario when those are not
>    configured explicitly.  (with the help of complete_context() in dhcp.c )
>    I see this improved the robustness of the logic and I think this is
> helpful for users.
> 
>    But "fallback" solution introduced in dnsmasq-2.58test6 does not
>    seem to pay attention to this default handling so much.  Am I wrong  ?
> 
>    then
>    to complete the "fallback" solution,  it is better for us to
>    pass other value, "relay address", in addition to
> "iface_addr"(=fallback), isn't it ?
> 
>    For "netmask" and "broadcast address" shown below, we need to go back
> to complete_context()
>    or execute equivalent codes here if we really want to make it.  I am
> not sure if this will pay or not.
>    ( this was why I updated the codes around complete_context() in
> dhcp.c at the beginning )
> 


The problem is that a DHCP client, once it is configured, does not need
to send requests via the relay agent. The client has the address of the
DHCP server (the server identifier) and it's allowed to send DHCPREQUEST
or DHCPINFORM packets straight to that address. Those requests don't go
via the relay, so the relay address is not available anywhere in the
packet received by the server. That's why that information is saved in
the context->router field. The problem than is if dnsmasq is restarted:
if the first packet comes direct, there's no way to fill in the
context->router field, so we have to cope with that gracefully.

Allowing clients to bypass the relay is probably a mistake in the design
of DHCP. DHCP for IPv6 doesn't allow it, I think. It is possible to
force the the client to always use the relay; either the relay can set
an option to control the server-id (RFC5107) or, in dnsmasq, the
--dhcp-proxy option can be used. Both of these force the server-id to be
the address of the DHCP relay and not the address of the DHCP server, so
that the relay is always used.

The netmask is a bit different. For local interfaces (no relay in use)
the default is set by reading the netmask configured into the interface.
That doesn't work for requests which come via a relay, and there's no
standard for a relay to add the netmask, so it _has_ to be configured in
the --dhcp-range to work with relays.

Actually, in most cases, it would work to assume the netmask implied by
the class of the address, pre-CIDR. Since most people will be using
RFC1918 addresses, that should get the right answer most of the time,
and is probably better than silently ignoring a dhcp-ranges without
netmasks when requests come via a relay. I'll add that code to the next
release, I think.

Cheers,

Simon.