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

Andre Kostur wrote:
>> 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.
> 
> And if your actual subnet mask is 255.255.255.192, your ranges are all
> "illegal" (well, they don't fall within a single subnet anyway...).  As
> a result, your DHCP server needs to know that information anyway....

If the actual subnet mask is 255.255.255.192 then the DHCP server logs
an error when it gets that information: It doesn't need to be configured
in advance unless you need it to flag errors in advance.

> 
>> 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, 
> 
> But can use the Link Selection Sub-option [RFC 3527] to designate a
> different IP to base that calculation on.

But that doesn't achieve the same thing: the link-selection option is
inserted by the relay, so the relay makes the decision about which
subnet to use. The aim here is to provide information about all the
available subnets to the server, so that is can do the address
allocation. A real-world example might be known clients on one subnet,
unknown clients on another.  Only the server knows which clients are
known, not the relay.

> 
>> (which one is not specified in any standard, as far as I 
>> know) The packet is then unicast by the relay to dnsmasq, 
> 
> The relay is supposed to put the IP of the interface upon which it
> originally heard the request.  If that interface has multiple IPs, then
> they are logically equivalent and shouldn't matter which one it puts in.
> 

That's true, but it assumes that the logical equivalence of the the
multiple addresses is encoded into the configuration of the DHCP server.
The motive for adding this option is to allow that information to be
communicated to the server without duplicating the configuration on both
relay and server.

>> 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.
> 
> Or like most (if not all) DHCP implementations that I've seen, they all
> provide the mechanism to define Adjacent Networks, Superscopes, Shared
> Networks, or some other term to designate that two (or more) subnets
> reside on a single interface.

I believe I covered that later in my message, this is a different way to
so the same thing which is simpler to configure.

> 
>> 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 
> 
> Uh, no.  It's been done for years.  Particularly in the cable modem
> deployment methods.  Cable operators frequently have multiple disjoint
> subnets being assigned to customers on a single cable interface.

I should have written this more clearly; "using a relay, it impossible
to configure dnsmasq to do address allocation over multiple subnets on
one physical network". Now I could remedy that by adding some variation
on the "shared network" configuration. But that's clumsy, and not in
general required. I already explained how this works for a network
directly connected to the server: the configuration is extremely easy
and works very well. To do the same thing with a relay needs the
sub-option which I proposed.

> 
>> 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.
> 
> I recall someone bringing up the use case at IETF 64.  And as I recall,
> the common opinion was "Nice idea, but the problem has been solved 15
> years ago with Adjacent Networks/Superscopes."
> 

Adjacent Networks is  one way to solve the problem; but it's not the
only one. The alternative used in dnsmasq works well and it widely
deployed (count the Linksys WRT-54Gs you encounter - they are mostly
running dnsmasq)

>> 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.
> 
> The Subnet Selection option [RFC 3011] for clients, and Link Selection
> Sub-Option [RFC 3527], plus the DHCP server already knowing the network
> topology covers these uses.

But not if the DHCP server doesn't know the topology. I can't see any way
to make dnsmasq behave in exactly the same for a relay-connected network as
for a directly-connected network using those options. (Both of which are
supported by dnsmasq.)

Cheers,

Simon.

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