Subject: [netlmm] GRE keys & Overlapping v4 addresses & DHCP relays

From: Joel Hortelius <[email-masked]>
Date: Wed, 04 Feb 2009 10:50:38 +0000

A question regarding overlapping v4 private space addresses;

How is this supposed to work with DHCP relay? If the DHCP server is
co-located with the LMA, and you force relayed DHCP traffic to be
tunneled using the approrpiate GRE keys (which would require both the
server and relay to be able to retrieve the mobile node's binding and
send the relayed packets according to the specified tunneling
mechanism), you'd still have to extend the DHCP server to be able to
use the GRE as a key to determine the lease. The remote id is ambigous,
since it merely specifies the v4Hoa, which is overlapping. 

If the DHCP server is not co-located with the LMA, you'd need to have
one DHCP server per 'domain' you're overlapping using its own unique
global address. If you're not using global addresses for the DHCP
server, you need to tunnel traffic using the mobile node's tunnel. But
to do this, especially from the DHCP server -> DHCP relay, you'd need to
parse any DHCP message entering the LMA and resolve the remote id in
order to resolve the binding and appropriate tunneling since the
destination address is the relay address, not the mobile node's. This I
think is ugly; I'd prefer not to have to parse application data in the
forwarding plane.

One option could be to extend the DHCP Support Mode to be able to
provide relay information; such as information to provide in a relay
agent link-selection sub option that would allow the DHCP server to
uniquely resolve the lease in question. IMHO it would be nice to add a
<server address> field in the DHCP Support option as well, so that the
LMA can specify the DHCP server to be used in the relay scenario.
The DHCP server per domain using private space addresses could be
resolved by extending above mentioned scheme and require the use of
server overload option as mentioned in the netlmm draft, and co-locate a
DHCP relay with the LMA, which could re-relay any DHCP requests based on
the link selection sub option to the appropriate DHCP server. 
However, it all comes down to providing some sort of information in the
DHCP requests that allows you to uniquely identify the binding we're
working on.

Furthermore, the MAG unless the DHCP relay is made GRE aware and able to
retrieve the downlink GRE key, have no possibility to resolve which
client a particular overlapping private space DHCP reply belongs to. The
remote id is ambigous. To deal with this, the DHCP relay would have to
add something along the lines of relay agent circuit ID as well in order
to retrieve the correct link and client. (Well, considering this a bit
more, I gather one could cache the client identifier or hardware address
in the DHCP request, and match the reply, so this is more implementation
dependent)

Regards,
Joel Hortelius

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 4 Feb 2009 22:45:47 -0800 (PST)

Hi Joel,

> since it merely specifies the v4Hoa, which is overlapping.

This is a good discussion point. But, the Overlapping IPv4 address
case is not really supported in the IPv4 support document in a
normative way. We did however list this use-case in the GRE key
exchange document, as an example of how the GRE keys provide the
flexibility in segregating user flows.

Now, to make this mode work when using DHCP based addressing. Two
cases:

DHCP server colocated with the MAG

- There is no issue here. The MAG exactly knows to which domain the mobile
   belongs and upon completing the PMIP signaling, the DHCP server
   on the local link will deliver the same. The need to segregate the
   DHCP flows on the LMA/MAG path is not required, as the DHCP is
   terminated locally.

DHCP Relay on the MAG:

- The DHCP Relay agent on the p2p link is provisioned to forward the
   DHCP packets to the domain to which the mobile belongs. This can be
   maintained on the per domain basis. So, the respective DHCP server
   instance will handle the DHCP requests for its domain. The other
   approach of using the realm information in address allocation and
   Also there are enough DHCP extensions for the relays to keyin such
   information as you pointed out below.

Thanks
Sri

> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>