DHCP relay with two interfaces

[Bjorn Andersson]

Thanks Simon for your reply. More inline:

On 4/24/07, Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:
> Bjorn Andersson wrote:
>
> ABSOLUTELY NOT, the network is BROKEN and no DHCP implementation will
> work properly with it - and neither will routing.

I'd like to argue about this. Whether it's broken or not, this is what
we have to live with since the number of IP addresses is limited. NAT
is everyday life both large and small networks, even more in Europe
and other parts of the world that has fewer IP addresses per capita
than the US.  Even though there would be more IP addresses to play
with private addresses and NAT is even preferred in some setups.

>
> Rule one of IP networks : "all addresses must be globally unique",
> though for the purposes of this you can modify that to "all addresses
> must be globally unique within the domain of networks/subnets served
> by the DHCP server".
>
> Rule two of IP networks " "all addresses must be globally routable",
> but again you can constrain that to "within the domain of
> networks/subnets served by the DHCP server".
>
> Your network breaks BOTH of these rules.

Yes, I am well aware of this. I am also well aware of how the Internet
and routing works. I have however not worked with DHCP servers in
other contexts than the most common. I understand that what I am doing
is more exotic than the normal setup, but thought that it would it
still would be fairly common. Apparently my assumption was wrong.

> The problem you have is that you have multiple networks sharing the
> same network address, so the routing is ambiguous. Is this packet for
> 10.1.1.1 to be sent to network A with the 10.1.1.0/24 subnet, or
> network B with the 10.1.1.0/24 subnet, or network C with ...

Yes, but this would not a problem with NAT. Also, I have no need or
desire to access hosts, say, from network A in network B. Everything I
want to do will work as I want if I could manage to do what I
described in my previous mail.

> You have to discount any NAT that the gateways may be doing because
> DHCP won't work unless it can route packets directly to a client at
> it's actual (not NATed) address.

My relay modifies the packets so that clients communicate directly
with the relay, and the server with the relay. I know, this is a hack,
but this accomplishes what I am trying to achieve. The server and
clients never communicate directly. Even though it is a hack, I don't
really see any downsides with it.

> You have two options :
>
> 1) Change the network addresses so that the different networks have
> different addresses, then you can use the 10.n.n.n address of the
> relay agent as the GIAddr.

But then the server will reply to a 10.n.n.n address which is private,
and not routable. And anyway, the criteria is that I am able to give
the same address to the same client independently of which network it
is in.

> 2) Bridge all the 10.n.n.n networks together so that they are one
> broadcast domain. You could try and be clever by blocking loads of
> broadcast traffic by filtering in the bridge(s), but the DHCP packets
> MUST be passed (at least some of them must be, it's going to be a
> non-trivial configuration).

Bridging the 10.n.n.n networks is not an option in my scenario.

> Either way, if your routing isn't unambiguous then the network isn't
> going to work !

The routing is handled by other means so that it will work. This is
actually why I need the setup as described. The clients can move
between networks and maintain a constant address, and thus maintain
ongoing IP protocol sessions, e.g TCP (without installing any new
client software, such as Mobile IP, which also is a criteria).

I'd rather not hack my own DHCP server... ;)

Regards,
Bjorn