Relay agents, NAT, and offers to giaddr

[Simon Hobson]

Alan DeKok wrote:

>  > Not true. It is true that relay agents are usually run on routers but
>>  it is NOT required - all that is required is that there is a relay
>>  agent somewhere on the client network.
>
>    The router usually has a better idea about network topology than
>other devices, which is a good reason for making it the relay agent.

Network topology is irrelevant - the relay agent needs to know just 
two items of information - it's own network and the dhcp server. It 
doesn't need to know anything whatsoever about anything else.

>  > No, it still will NOT work. The GIAddr will still be a non-routable
>>  rfc1918 address.
>
>    That's really an implementation choice.  NAT boxes already keep state
>for UDP queries and responses, and re-write packet contents.  There's no
>reason the NAT box can't do NAT for DHCP relay, too.  In that case,
>giaddr could be its external IP.
>
>    i.e. NAT boxes already re-write packet contents for things like icmp
>port unreachables, why not do the same for DHCP?

There is a BIG difference. Rewriting addresses is fairly simple as 
(usually) the outside device doesn't need to know anything about the 
internals of the network. DHCP however needs to have intimate 
knowledge of what is behind the NAT.

I had considered that you could make a shared network with the 
internal network and the public address of the NAT gateway, then get 
the NAT gateway to use it's public address as GIAddr - it's a hack 
but it would deal with broadcast traffic by using a non-complaint 
relay agent and corresponding manual intervention on the server.

It doesn't deal with the client renewing though. That would need 
significant rewriting of the server to handle renewal requests that 
come from a different IP address to the lease being renewed. IFF you 
think you can write a workable method for dealing with it, then the 
way to address it is through the standards bodies - good luck !

Far better would be to push for faster adoption of IP6 which will 
make NAT obsolete and completely remove the problem. I'm all for that 
- I've been doing work with SIP at work and the sooner we see the end 
of NAT the better ! There are many things that NAT breaks, it's just 
that for the most common ones (FTP for example) there are application 
level gateways in most NAT boxes. BTW, with SIP it is NOT possible to 
write a universal ALG that will ALWAYS correctly rewrite a SIP packet 
- but that's not a discussion for this list.

>  >     If the NAT box puts its external address in the giaddr field, the DHCP
>>  server is going to assign an external address to the client and send this
>>  back to the NAT box.
>
>    Again, this is an implementation choice.  The giaddr field is simply
>a key.  The DHCP server can respond with allocations for different
>networks based on the giaddr fields, which would seem to be the case here.

But the key feature is that the server must select an address which 
is on the same subnet (or shared network) as the GIAddr.

>    In a similar situation, named has "views".  DHCP could do something
>similar.
>
>    I'm not saying it should be done, but just that it's possible.  The
>current method are proven, but that doesn't preclude extending the
>behavior of DHCP implementations.

The complications are significant. I personally do not believe that 
the effort involved would be worth it since there are always 
alternatives. In any case, this is only the second or third time in a 
good few years that I can recall the question being asked - hardly a 
mass request !

>  >     It seems easier just to put a DHCP server on the internal network, or
>>  build it into the NAT box.
>
>    Yes, that's often the case.

Indeed.