Subject: [netlmm] IPR Concerns on the use of DHCP Server Identifier Override Sub-option

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 26 Mar 2009 15:07:51 -0400

Hello all,

I have concerns about using the DHCP Server Identifier Override
Sub-option in draft-ietf-netlmm-pmip6-ipv4-support-10. The DHCP Server
Identifier Override Sub-option is defined in RFC 5107. RFC 5107 has a
Cisco IPR.

This DHCP option basically allows the MAG, in the DHCP relay scenario,
to force itself to be on the path for subsequent DHCP messages sent to
the LMA after the initial session setup. I don't believe this is
required. 

The draft currently does say it is optional to use this. Sri and I have
been discussion this for nearly 6 months now. The earlier versions of
the document said this is required to be implemented by the MAG. But
after offline and mailing list discussions, it turned out that it is not
really required on the MAG. So now it has been made optional.

But there is still a basic question on why use this option at all.
That's not clear to me. My suggestion is to remove the reference to RFC
5107 in draft-ietf-netlmm-pmip6-ipv4-support-10. If there are folks
still interested in implementing this option and using it with PMIPv6,
it would perhaps better if this is described in a separate document.

Sri and I have already discussed this quite a bit. I would like to hear
other opinions.

Vijay

---

From: Joel Hortelius <[email-masked]>
Date: Fri, 27 Mar 2009 08:41:55 +0000

Hi Vijay;

It pretty much depends on how complex scenarios the spec is supposed to
handle. For example, the setup scenario in the GRE key draft, section
3.1 would be difficult to solve with the DHCP relay without using the
server override, since forwarding the DHCP reply without the agent
information would be ambigous given that two nodes have the same v4 hoa
(granted, even if you add the remote id you dont have enough forwarding
information, but you can add extra information such as the relay agent
link-selection sub opt to solve it).

Regards,
Joel Hortelius

On Thu, 2009-03-26 at 15:07 -0400, Vijay Devarapalli wrote:
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: Joel Hortelius <[email-masked]>
Date: Fri, 27 Mar 2009 08:41:55 +0000

Hi Vijay;

Regards,
Joel Hortelius

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Mar 2009 16:50:23 -0700

Hi Joel,

> link-selection sub opt to solve it).

For the initial DHCP messages, the MAG as a DHCP relay is required to 
add the DHCP relay agent information option. This would allow the LMA to 
distinguish between two different requests.

For subsequent renewal of the IPv4 address, the LMA just needs to check 
the mobile node identity against the IPv4 address it allocated earlier 
when it receives a DHCPREQUEST for renewal directly from the mobile 
node. It shouldn't matter if two different mobile nodes have the same 
private IPv4 home address. Right?

What am I missing?

Vijay

---

From: Joel Hortelius <[email-masked]>
Date: Tue, 31 Mar 2009 08:47:38 +0000

Hi Vijay;

Well, I may very well be the one missing something here. Probably too
focused on my own implementation details. Using the [HoA,
ClientID/HwAddr(which I assume is what you call the mobile node id?)]
would be a unique key for the lease, granted. However, when having
identical private space routing domains, routing information quickly
becomes ambigous. The LMA can determine forwarding based on receiving
interface or GRE keys. When applications located on the LMA itself
attempts to send traffic(such as the co-located DHCP server) to the
private space addresses, the destination will be ambigous. The
co-located DHCP server would have to be able to retrieve the tunneling
information from the LMA, or it would not be able to send the reply
correctly using the correct GRE keys allowing the MAG to forward it to
the correct node. It does add complexity and higher demands on
integration between the modules, but not impossible to do. I find it
cleaner to have the functions separated; but as I said, since its doable
and perhaps a rather obscure setup, I'll not argue.

Regards,
Joel Hortelius

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 31 Mar 2009 08:10:17 -0500

> 
> The draft currently does say it is optional to use this. Sri 
> and I have been discussion this for nearly 6 months now. The 
> earlier versions of the document said this is required to be 
> implemented by the MAG. But after offline and mailing list 
> discussions, it turned out that it is not really required on 
> the MAG. So now it has been made optional.
> 
> 5107 in draft-ietf-netlmm-pmip6-ipv4-support-10. If there are 
> folks still interested in implementing this option and using 
> it with PMIPv6, it would perhaps better if this is described 
> in a separate document.
> 
[Ahmad]
Yes. I agree with this proposal.

> Sri and I have already discussed this quite a bit. I would 
> like to hear other opinions.
> 
> Vijay