Re: [netlmm] Consensus call: RFC5107 based DHCP message intercept at MAG

[Vijay Devarapalli <[e-mail]>]

Hi Ryuji,

On 4/11/09 7:57 PM, "Ryuji Wakikawa" wrote:

> Hi Vijay and Vidya,
> 
> On 2009/04/10, at 1:34, Vijay Devarapalli wrote:
> 
>> Hi Vidya,
>> 
>> One clarification. There is no need for the MAG to intercept the
>> unciast
>> DHCP requests from the MN to the DHCP server co-located with the
>> LMA. It
>> can treat the DHCP messages as regular traffic from the MN. The LMA
>> checks if the MN is requesting the same address it has been allocated.
> 
> You are right only if DHCP server is co-located with the LMA.
> This document also covers the other scenario where DHCP-server can be
> solely located in PMIP6 domain.
> We should not mandate to locate DHCP server at LMA.

We have discussed this scenario in the past. I don't think scenario is
necessary. IMO, the MAG should only talk to the LMA. If there is an external
DHCP server (not co-located with the LMA), then it should be the LMA taking
to the DHCP server. Having two control plane protocols on the MAG, both
managing the address for the mobile node is not a good idea.

In addition, you have the issue that Rajeev was brining up. Even in the DHCP
relay case, the client would now see different DHCP server IP address when
there is a MAG-MAG handover, if you force the MAG to be on the path for the
DHCP messages.

Vijay
 
> To verify renewing DHCP message at the solely located DHCP-server, we
> need additional interface
> between DHCP server and LMA (to exchange binding status).
> This is totally out of scope in this document.
> 
> Then, available options we have are
> - using RFC 5107
> - MAG inspects all the packets to capture DHCP unicast message for
> renew.
> 
> I don't want to increase the operator's opportunity of packets'
> inspection.
> If MAG has packets inspection feature because of IPv4 support spec.,
> operators can easily start some other operations (often annoying) by
> their nature..
> 
> As a conclusion I want to keep 5107 in the document.
> 
> thanks
> ryuji
> 
> 
> 
>> 
>> 
>> On the consensus call, my preference is to remove this entire optional
>> mechanism.
>> 
>> Vijay
>> 
>>> -----Original Message-----
>>> From: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Narayanan, Vidya
>>> Sent: Thursday, April 09, 2009 9:48 PM
>>> To: [e-mail]
>>> Subject: [netlmm] Consensus call: RFC5107 based DHCP message
>>> intercept at MAG
>>> 
>>> An issue has been raised on the inclusion of the DHCP Server
>>> Identifier Override sub-option (specified in RFC5107) as a
>>> means for the MAG to intercept the MN's DHCP messages sent to
>>> the DHCP server.  This option allows the relay (MAG) to act
>>> like the DHCP server and more directly get the MN to even
>>> address the RENEW DHCP requests to itself, so that the MAG
>>> can include the Relay Agent option in those messages as well.
>>> Without this option, the relay in the MAG would need to
>>> intercept all DHCP messages.
>>> 
>>> In PMIPv6, all packets from the MN will go through the MAG -
>>> from an implementation perspective, my interpretation is that
>>> the use of RFC5107 is likely to make a difference in the
>>> extent of hardware based forwarding that is made feasible in
>>> the MAG.  Otherwise, functionally, the MAG should be able to
>>> intercept all DHCP messages even without this option.
>>> 
>>> The issue raised is primarily from an IPR perspective -
>>> please see the following link for the IPR terms associated
>>> with RFC5107:
>>> 
>>> https://datatracker.ietf.org/ipr/124/
>>> 
>>> I would like to hear WG input on whether you prefer to keep
>>> the option in the document or take it out.  If you can
>>> provide an explanation for the choice you make (IPR and/or
>>> technical), it will be useful.
>>> 
>>> Please respond to the list by April 15th, 2009.
>>> 
>>> Thanks,
>>> Vidya <as co-chair>
>>> _______________________________________________
>>> netlmm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>> 
>> _______________________________________________
>> netlmm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netlmm
>