Re: [dhcwg] Question: in RFC3046 why did Agent Subnet Mask Sub-optiondie

David W. Hankins wrote:
> On Tue, Mar 06, 2007 at 09:35:08PM +0000, Simon Kelley wrote:
>> The Agent Subnet mask would provide the needed information and make 
>> configuration for remote networks work in the same way as for local 
>> networks. This would make my life easier because my users would no 
>> longer omit netmask information and wonder why their DHCP doesn't work.
> 
> Except that some DHCPv4 relays do not have addresses on the networks
> they are relaying...so they don't have this knowledge.
> 
> Some don't set giaddr, but do provide the relay agent option.  So
> a subsequent relay agent that does set giaddr would be disallowed
> from placing their own relay agent option in the packet and
> couldn't deliver the subnet mask if they had it...
> 
> Some do set giaddr (to an address on a different interface), and
> therefore have to be configured with a subnet selection option
> contents.  So far as I know, none of them expect 'CIDR notation'
> for this configuration value, but I suppose it is at least
> possible that they might be made to.

These configurations are clearly not suitable for use with a scheme
where the DHCP server derives network topology. There is no reason it
should become mandatory for either relay agents or DHCP servers to use a
netmask sub-option, but it easy to demonstrate situations in which using
them would be advantageous.

> 
> But I'm more curious about what you intend to do with multiple
> subnets on one broadcast domain...which subnet should the relay
> provide the mask for?

This is a very valid question: reading back though the archives, it
looks like it's one of the things which was worying Ted Lemon about the
netmask sub-option. (I think: Ted can, of course, correct me if I've
second-guessed him wrong here.)

> 
> Are relays going to be required to know about all the subnets
> attached to a physical interface?  If they're too dumb to have
> an IP address, but smart enough to be able to supply useful
> information in a relay agent option, are they going to need a
> way for routers to inform them what subnets they should
> advertise to the DHCP server?

You have clearly followed the same paths as me: I think relay-added
option which contains all the subnets existing on the physical network
from which a relay received a packet would be exactly what's required here.
> 

> I don't like the vector to this line of reasoning.

Would you care to explain why?
> 
>> To answer your question another way, I have a DHCP server which doesn't 
>> need to be explicitly configured with the network topology, it derives 
>> it. To make this work with relays need the relays to provide netmask 
>> information.
> 
> I don't think this will work without creating some sort of
> "subset of compatibility" (similar to the client-identifier
> and domain-name options).
> 
> 

You should look at dnsmasq, which makes it work fine.

Consider first an interface on the machine running dnsmasq which has two
two addresses, say 192.168.0.0/24 and 192.168.1.0/24. Dnsmasq is
configured which available address ranges on each of these networks and
on another network.

dhcp-range=192.168.0.2,192.168.0.100
dhcp-range=192.168.1.2.192.168.1.100
dhcp-range=192.168.2.2,192.168.2.100

Note that no netmask information is provided, and dhcp-ranges are not
explicitly associated with a physical interface.

When a broadcast arrives at the interface, dnsmasq starts with the list
of IP-address/netmask pairs associated with the interface where packet
was received, and infers which dhcp-range statements are valid. In this
case 129.168.0... and 192.168.1.... but _not_ 192.168.2..... That set of
address ranges is then used to allocate an address.

If the same thing occurs but the broadcast is received by a relay, then
the relay can  put only one address into giaddr, (which one is not
specified in any standard, as far as I know) The packet is then unicast
by the relay to dnsmasq, which can only use the value of giaddr to infer
valid address ranges, hence it ends up with either 192.160.0.... _or_
192.168.1.... in the set of usable address ranges, but not both.

In the relay case, dnsmasq needs to configured with the netmask of
whichever subnet the relay chose: it has no way to find it automatically
and can't infer which address-ranges are valid without this information.
(In contrast for the local-interface case, it can just ask the kernel.)

So, using a relay, address allocation over multiple subnets on one
physical network is impossible, and it requires that netmask information
be duplicated in the relay and the server. Both of these problems could
be fixed by a relay sub-option which allows the relay to send a list of
IP-address/netmask pairs to the server. The server would then have the
same information in the relay case that it has in the directly-connected
case.

Another way to think about this is that giaddr has two functions: it is
the address to which the server unicasts packets which it wishes to be
relayed back to a client, and it's a handle which encodes the place in a
the network topology from which a broadcast originated, and therefore
drives the address allocation process. [1] A relay-suboption which
transmits the list of subnets associated with he pyhsical network on
which a broadcast was received can be seen as replacing the second of
these functions, but only when both relay and server support it.

Cheers,

Simon.

[1] I believe that the ISC server makes this more explicit with "shared
    network" declarations: which can be read as saying "if a packet
    arrives with giaddr on subnet A, you can allocate an address from
    subnets A,B,C
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg