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

[xiajinwei <[e-mail]>]

Hi Vijay and Ryuji,
	
	Sorry for my jumping this thread. 


> > 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.

I guess the scenario you describe is a set of LMA share sole DHCP-S, in this
case LMA should act as DHCP-R if it will be aware of DHCP state changes for
MN, thus it is LMA using RFC5107 rather than MAG.  it seems RFC5107 is still
kept in this document.


BR
	Jinwei

> 
> 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
> > 
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm