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

["Andre Kostur" <[e-mail]>]

Comments inline

> -----Original Message-----
> From: Simon Kelley [mailto:[e-mail]] 
> Sent: Friday, March 09, 2007 3:50 AM
> To: David W. Hankins
> Cc: DHC WG
> Subject: Re: [dhcwg] Question: in RFC3046 why did Agent 
> SubnetMask Sub-optiondie
> 
> 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.

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....

> 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.

> (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.

> 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.

> 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.

> 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."

> 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.

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg