[Dnsmasq-discuss] rfc3527 support

Takayuki Kaiso tkaiso2 at thinktube.com
Tue May 10 03:37:17 BST 2011


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



More information about the Dnsmasq-discuss mailing list