David W. Hankins wrote:
> On Fri, Mar 09, 2007 at 11:50:28AM +0000, Simon Kelley
wrote:
>
>>>I don't like the vector to this line of
reasoning.
>>
>>Would you care to explain why?
>
>
> Sure.
>
>
>>You should look at dnsmasq, which makes it work
fine.
>
>
> I know dnsmasq works, I meant for the relay case.
>
> Adopting a change like this would create a 'subset of
compatibility'
> where dnsmasq is compatible with certain relays (and
network designs
> it turns out) but not others.
>
> It "doesn't work" for any device that adds
relay agent options and
> either doesn't know about any prefixes on that network
(such as a
> switch), or doesn't know about /all/ of the prefixes on
that network
> (such as one of multiple routers, or one of multiple
hosts on that
> network).
>
> If it were just a 'dnsmasq works with relay A but not
B' thing, I
> might be convinced if there were a really good reason
(but I think
> 'not configuring the network mask' isn't good enough).
But 'network
> architecture A but not B' is pushing it even further
for me.
This is already the situation for dnsmasq: currently
"shared networks"
work with directly connected networks but for networks
behind relays,
shared networks are not allowed. So providing this facility
doesn't add
another exception, it allows networks behind relays to work
in the same
way as directly connected networks and removes the anomally.
For relays
which don't support the new option, nothing changes.
>
> DHCP tries hard not to care how the network is put
together. It is
> a bad vector to create DHCP protocol work that dictates
a network
> design,
I don't think it does.
> and intentionally introduces relay<->server
compatibility
> problems.
>
I have some sympathy with this, but, at least for dnsmasq,
it's possible
to argue that it reduces compatibility problems.
Cheers,
Simon.
_______________________________________________
dhcwg mailing list
dhcwg ietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
|
