Subject: [dhcwg] Question: in RFC3046 why did Agent Subnet Mask Sub-option die

From: Simon Kelley <[email-masked]>
Date: Tue, 06 Mar 2007 20:42:46 +0000

What was the reasoning behind removing the Agent Subnet mask option 
during the gestation of RFC3046? It was there in

draft-ietf-dhc-agent-options-08

and gone in

draft-ietf-dhc-agent-options-09

I ask because I have an application where it would be very useful.

I realise that this is a long time ago, which begs a meta-question, do 
publically-accessible archives exist for the DHC working group mailing 
list, stretching back that far? I found

    http://www1.ietf.org/mail-archive/web/dhcwg/current/index.html

but that doesn't seem to allow access to historic archives.

Cheers,

Simon.

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

---

From: Mark Stapp <[email-masked]>
Date: Tue, 06 Mar 2007 16:50:26 -0500

yes, of course. submitting an individual draft and then presenting it to 
the working group would be exactly the right thing to do.

-- Mark

Simon Kelley wrote:
> Mark Stapp wrote:
>> Simon,
>>
>> I still have some of the old emails from 1999-2000 discussing the 
>> issue. there was an argument made during the last-call that the 
>> specification of that subnet suboption in -08 was insufficient and 
>> might lead to interoperability problems. there were folks who didn't 
>> object to it as it was, but Mike Patrick (the author) went ahead and 
>> removed that suboption in order to address the objection. it sounded 
>> as if he was planning to submit a separate draft, but I can't find any 
>> evidence that he ever did. 
> 
> I wonder, would it be possible to submit a draft now and restart this 
> process? (presumably leading ultimately to a new RFC?) Since I have a 
> real application for this option, that could help to nail down the 
> specification.
> 
> Cheers,
> 
> Simon.
>

---

From: "Andre Kostur" <[email-masked]>
Date: Tue, 6 Mar 2007 13:05:47 -0800

Turning the question around, why do you feel that it is necessary?
Presumably the DHCP server already knows the network topology and thus
knows what the subnet mask is on whatever network the client is
requesting from...

> -----Original Message-----
> From: Simon Kelley [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 12:43 PM
> To: [email-masked]
> Subject: [dhcwg] Question: in RFC3046 why did Agent Subnet 
> Mask Sub-optiondie
> 
> What was the reasoning behind removing the Agent Subnet mask 
> option during the gestation of RFC3046? It was there in
>

---

From: Simon Kelley <[email-masked]>
Date: Tue, 06 Mar 2007 21:42:58 +0000

Mark Stapp wrote:
> Simon,
> 
> I still have some of the old emails from 1999-2000 discussing the issue. 
> there was an argument made during the last-call that the specification 
> of that subnet suboption in -08 was insufficient and might lead to 
> interoperability problems. there were folks who didn't object to it as 
> it was, but Mike Patrick (the author) went ahead and removed that 
> suboption in order to address the objection. it sounded as if he was 
> planning to submit a separate draft, but I can't find any evidence that 
> he ever did. 

Cheers,

Simon.

---

From: Mark Stapp <[email-masked]>
Date: Tue, 06 Mar 2007 16:21:19 -0500

Simon,

he ever did. feel free to email me if you'd like me to forward the 
actual emails to you...

Regards,
Mark

---

From: Simon Kelley <[email-masked]>
Date: Tue, 06 Mar 2007 21:35:08 +0000

> knows what the subnet mask is on whatever network the client is

I maintain dnsmasq <http://www.thekelleys.org.uk/dnsmasq/doc.html> which 
(despite its name) is, amongst other things, an easy to configure DHCP 
server.

For local networks, the only _required_ configuration is one or more 
ranges of addresses to allocate from: everything else is automagically 
inferred from the network configuration of the machine. For networks 
where the host running dnsmasq doesn't have a interface (ie where a 
relay agent is in use), this breaks down because the netmask is not 
available and it has to be manually configured.

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.

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.

Cheers,

Simon.

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 8 Mar 2007 10:06:02 -0800

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

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?

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?

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

> it. To make this work with relays need the relays to provide netmask 

I don't think this will work without creating some sort of
"subset of compatibility" (similar to the client-identifier
and domain-name options).

-- 
ISC Training!  http://www.isc.org/training/  [email-masked]
Washington DC area, April 16-20 2007.  DNS & BIND, DDNS & DHCP.
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Kelley <[email-masked]>
Date: Fri, 09 Mar 2007 11:50:28 +0000

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

> subnets on one broadcast domain...which subnet should the relay

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

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

---

From: "Andre Kostur" <[email-masked]>
Date: Fri, 9 Mar 2007 07:32:37 -0800

Comments inline

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

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

---

From: Simon Kelley <[email-masked]>
Date: Fri, 09 Mar 2007 16:38:38 +0000

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

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

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

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

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

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

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Mar 2007 12:38:13 -0700

> second-guessed him wrong here.)

My personal feeling on the relay agent subnet mask issue is that I  
don't see any reason why we shouldn't just specify a list of subnets  
that are valid on the client's link, in the same format as the  
classless static routes option, rather than doing the incomplete  
solution of simply providing a subnet mask that implies a prefix  
based on the relay agent's IP address.   I think that that solution  
has limited utility, and in the single-subnet case providing a CSR- 
like option to specify the one prefix that's valid on the link isn't  
going to add more than three or four bytes as compared to sending  
just the subnet mask.

I have minimal recollection of the debate over the subnet mask option  
way back when - that's been a very long time ago now.   I don't think  
we could meaningfully use any recollections I have to inform this  
discussion... :'}

---

From: Ralph Droms <[email-masked]>
Date: Sun, 18 Mar 2007 14:20:46 -0400

Expanding on Ted's theme a little - if we're going to consider extensions to
DHCP that can automate the process of configuring the DHCP server, we ought
to take a little time to consider other, similar extensions and define them
all at once rather than one at a time...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Mar 2007 09:31:21 +0100

> all at once rather than one at a time...

Best is the enemy of good enough, so I don't think we should delay  
forever if there is some demand for this functionality.   This is  
certainly something that would be optional to implement, so I don't  
think it's a problem to define a standard for it.   I mentioned the  
more detailed option style because it's an obvious enhancement, but  
this really isn't a very complicated use case - I don't think we're  
going to come up with anything revolutionary here if we wait.

So my personal feeling is that using the CSR format is sufficient,  
unless someone has a better idea, and that if there is demand for  
this we should do it.   To me the big question is whether there's  
demand for it.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 19 Mar 2007 04:43:05 -0400

We only have one request for this for "automatic configuration" ... And
that server already needs some configuration (such as the addresses
available for DHCPv4), so it seems like extending that server's
configuration to allow the subnet mask (length) to be specified isn't a
severe handicap.

While there may not be any harm in the Relay Agent providing this
information, it would be years before most relays would even have the
support for this so if that server is going to be used in these
environments, its going to need a workaround until such time as this
option has gone through DHC WG Last Call, IETF Last Call, and is
available in relay agents.

Our assumption has always been that you need to configure the DHCP
server with this information (and DHCPv6 has no similar options).

- Bernie 

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Monday, March 19, 2007 4:31 AM
To: Ralph Droms (rdroms)
Cc: DHC WG
Subject: Re: [dhcwg] Question: in RFC3046 why did Agent Subnet
MaskSub-optiondie

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 19 Mar 2007 10:43:30 +0100

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

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, and intentionally introduces relay<->server compatibility
problems.

If you were curing cancer or something, that's a different game.

---

From: Simon Kelley <[email-masked]>
Date: Mon, 19 Mar 2007 13:52:36 +0000

>> all at once rather than one at a time...

I proposed in the draft which went to Ted an extension to the CSR format
to include the broadcast address, for free in common cases. That would
probably count as a "similar extension".

Another useful one might be a "default option override" which allows the
relay to tell the server "in the absence of explicit configuration, use
value Y for option X" An obvious use for that would be default gateway -
a relay may be in a much better position to create a good default for
that then a  remote server. It should probably be general, and allow the
default for any option to be set.

Cheers,

Simon.

---

From: Simon Kelley <[email-masked]>
Date: Mon, 19 Mar 2007 22:22:08 +0000

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

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