Hi, Simon
I do appreciate your comments, it is so helpful for me.
Basically, I think I am sharing your points.
Do you have comments/thoughts with the following points ?
thanks for taking one more time again.
The problem is that a DHCP client, once it is configured, does not need
to send requests via the relay agent. The client has the address of the
DHCP server (the server identifier) and it's allowed to send DHCPREQUEST
or DHCPINFORM packets straight to that address. Those requests don't go
via the relay, so the relay address is not available anywhere in the
packet received by the server.
then
can we say stateful solution by context->relay is NOT helpful if
- DHCP sever (dnsmasq) restart (as you mentioned )
- there are more than one relay agents sharing a context.
(this can happen with the help of rfc3527/rfc3011)
Allowing clients to bypass the relay is probably a mistake in the design
of DHCP.
I see the point, then how do you think about "roaming" case by the dhcp
clients.
Is "roaming" out of the question ? :-)
Due to the nature of mobility, these clients hope to send his DHCPREQUEST
- via the relay agent, or
- straight(physically) without relay agent or
- via different relay agent after roaming.
< example >
- AP1,AP2,AP3, ...AP19 and DHCP server, those are connected via L3
say, those WAN interfaces have 10.0.1.0/8 address
- LAN interfaces of these APs shares 192.168.1.x/24
this is "common flat subnet" over L3.
- DHCP Relay is running on all of the APs.
- iPod, Iphone are roaming around those APs
Note1: some people say we should build simple L2 bridge network for
this goal, but this can not be a good answer because
L2 lacks the scalability and topological flexibility.
Note2: Regarding the case of "roam to different APs", we also need to
provide another solution to help the client to work around "default
gateway"
issue across roaming, but there are some solutions for this,
so I will not go into detail of it here.
Note3: With rfc3527, dhcp relay(s) put his 10.0.1.x address in giaddr and
put 192.168.1.x for link selection sub-option field.
The problem is that a DHCP client, once it is configured, does not need
to send requests via the relay agent. The client has the address of the
DHCP server (the server identifier) and it's allowed to send DHCPREQUEST
or DHCPINFORM packets straight to that address. Those requests don't go
via the relay, so the relay address is not available anywhere in the
packet received by the server. That's why that information is saved in
the context->router field. The problem than is if dnsmasq is restarted:
if the first packet comes direct, there's no way to fill in the
context->router field, so we have to cope with that gracefully.
Allowing clients to bypass the relay is probably a mistake in the design
of DHCP. DHCP for IPv6 doesn't allow it, I think. It is possible to
force the the client to always use the relay; either the relay can set
an option to control the server-id (RFC5107) or, in dnsmasq, the
--dhcp-proxy option can be used. Both of these force the server-id to be
the address of the DHCP relay and not the address of the DHCP server, so
that the relay is always used.
The netmask is a bit different. For local interfaces (no relay in use)
the default is set by reading the netmask configured into the interface.
That doesn't work for requests which come via a relay, and there's no
standard for a relay to add the netmask, so it _has_ to be configured in
the --dhcp-range to work with relays.
Actually, in most cases, it would work to assume the netmask implied by
the class of the address, pre-CIDR. Since most people will be using
RFC1918 addresses, that should get the right answer most of the time,
and is probably better than silently ignoring a dhcp-ranges without
netmasks when requests come via a relay. I'll add that code to the next
release, I think.
Cheers,
Simon.
Thanks a lot and cheers.
Takayuki Kaiso
