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

["Ahmad Muhanna" <[e-mail]>]

Hi Ryuji,

> 
> The operator needs to place the DHCP entities supporting 
> RFC5107 in their PMIP domain.
> RFC5107 said
> "When configuring a DHCP relay agent to use this suboption, 
> the administrator of the relay agent should take into account 
> whether or not the DHCP server to which the message will be 
> relayed will correctly understand this suboption."
> 
> If DHCP server does not support RFC5107, it should perform 
> promiscuous interception of all the MN's packets.

[Ahmad]
Then, there is a potential for the MAG to do both of these options NOT
only one. I believe that should be captured in the draft some how.

> 
> regards,
> ryuji
> 
> 
> >
> >
> > Thanks!
> >
> > Regards,
> > Ahmad
> >
> >
> >> -----Original Message-----
> >> From: Muhanna, Ahmad (RICH1:2H10)
> >> Sent: Wednesday, April 15, 2009 10:39 AM
> >> To: 'Ryuji Wakikawa'
> >> Cc: 'Narayanan, Vidya'; 'Vijay Devarapalli'; 'Koodli, Rajeev'; 
> >> '[e-mail]'
> >> Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP 
> >> messageintercept at MAG
> >>
> >> Hi Ryuji,
> >>
> >>>
> >>>> Hi Vidya and Vijay,
> >>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Vijay Devarapalli [mailto:[e-mail]]
> >>>>>> Sent: Friday, April 10, 2009 8:34 AM
> >>>>>> To: Narayanan, Vidya; Koodli, Rajeev; [e-mail]
> >>>>>> Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP 
> >>>>>> messageintercept at MAG
> >>>>>>
> >>>>>> Hi Vidya,
> >>>>>>
> >>>>>>> Hi Rajeev,
> >>>>>>> If the MAG does not intercept DHCP messages, it will be
> >>>>> unaware of
> >>>>>>> any DHCP state changes (e.g., lease termination, IP address 
> >>>>>>> change/release, etc.) for the MN.  We don't have
> >>>>> mandatory defined
> >>>>>>> behavior in the LMA to avoid such potential state
> >> changes.  So,
> >>>>>>> short of using RFC5107, the MAG needs to intercept DHCP
> >>>>> messages to
> >>>>>>> figure this out.
> >>>>>>
> >>>>>> The LMA sends a binding revocation to the MAG if it cannot
> >>>>> grant the
> >>>>>> request from the MN to renew the IPv4 address.
> >>>>>>
> >>>>>> Similary, if the MN releases the IPv4 address, the LMA
> >>> would again
> >>>>>> send a binding revocation to the MAG to remove the 
> IPv4 binding.
> >>>>>>
> >>>>>
> >>>>> Binding revocation is not part of the base spec - this assumes 
> >>>>> support for binding revocation on the LMA and MAG and we
> >>> cannot write
> >>>>> the IPv4 spec assuming that, unless we want to make it a
> >> normative
> >>>>> requirement to do this.
> >>>>>
> >>>> [Ahmad]
> >>>> I believe having a normative requirement to use Binding
> >> Revocation,
> >>>> which is a MEXT/Netlmm wg item, is a much cleaner solution and 
> >>>> separation between the protocols that managed the MN BCE
> >> and those
> >>>> which is meant for host configuration.
> >>>
> >>> I can't agree on this. BR is now big spec., it is much
> >> better to refer
> >>> to RFC5107 since DHCP is needed for IPv4 support.
> >>> The use of RFC5107 is much straightforward.
> >>>
> >> [Ahmad]
> >> This is absolutely a very interesting argument.
> >> The whole concept of this DHCP kluge (as I prefer to call 
> it) is for 
> >> the MAG to be aware of the state of the IPv4 address.
> >> In other words, in order for the MAG and the LMA to stay 
> in sync with 
> >> respect to resources and state of the MN BCE. Is NOT that 
> what we are 
> >> trying to do here?
> >>
> >> If maintaining a synchronized state between the MAG and 
> the LMA with 
> >> respect to MN BCE is important, then I assume that other scenarios 
> >> where synchronization between the MAG and the LMA is 
> important too. 
> >> Right?
> >> Then using the same logic, BR should be as important to be 
> used. If 
> >> BR is needed anyway, it seems that you do not have a 
> problem solving 
> >> this issue by a normative text to BR:)
> >>
> >>
> >>>> May be another idea (I understand that is way too late) is
> >>> to propose
> >>>> an extension for the base protocol which allows the LMA to
> >>> initiate an
> >>>> update to the MAG by sending a Binding Update Trigger "BUT"
> >>> informing
> >>>> the MAG with the IPv4 home address release. The MAG 
> either Ack by 
> >>>> sending a PBA or send a refresh PBU.
> >>>
> >>> Hmm, i dont think this is good solution.
> >>> If MAG can detects DHCP renew, it can always send PBU to 
> verify the
> >>> IPv4 address leasing time.
> >>
> >> [Ahmad]
> >> Okay, you should take that suggestion with a grain of salt:) 
> >> Although, this is nothing but another way of using BR message and 
> >> calling it something else:) In other words, if BR is used, 
> then we do 
> >> not have any problem in the case of IPv4 address release. 
> However, in 
> >> the renewal case, BR can still be used if the proper trigger is 
> >> defined and used.
> >>
> >> However, the fundamental issue here is the clean 
> separation between 
> >> two control protocols that are used for two different things. 
> >> Otherwise, as I said, it becomes spaghetti, and from architectural 
> >> point of view, that is not good and a recipe for more 
> kluges in the 
> >> future.
> >>
> >> For example, If I remember correctly, MIP4-gen-ext did not 
> advance, 
> >> after passing wg LC, because DHCP experts told us that Host 
> >> configuration needs to be left for DHCP and MIP4 signaling for 
> >> mobility management. I personally supported that view. In 
> that case, 
> >> MIP4 signaling should be enhanced to make DHCP works naturally 
> >> without MIP4 signaling involvement or kluge:)
> >>
> >> Similarly, we should propose a PMIP6 system that works 
> naturally with 
> >> other control protocols without further inter-protocol mixing here 
> >> and there.
> >>
> >> BTW: When the DHCP-Relay adds its Identities sub-option to 
> force the 
> >> MN to send its future DHCP requests to it, is that server still 
> >> called a Relay-DHCP server? I think it should be called 
> >> Half-Relay-Half-Server:)
> >>
> >>>
> >>> ryuji
> >>>
> >>>
> >>>>
> >>>>>> Anyway, in PMIPv6, the renew lifetime to the IPv4 home
> >>>>> address is tied
> >>>>>> to the binding cache lifetime. These piece are not loosely
> >>>>> connected.
> >>>>>>
> >>>>>
> >>>>> I'm not seeing text that mandates tying these two
> >>> lifetimes together
> >>>>> - can you please point me to it?  Again, unless the
> >> requirement is
> >>>>> normative, we'll need to cover the cases when things can
> >>> fall out of
> >>>>> sync.
> >>>>>
> >>>>>> So you don't need the MAG to intercept the DHCPREQUEST
> >>>>> messages sent
> >>>>>> for renewing the IPv4 address.
> >>>>>>
> >>>>>>> I also want to highlight the difference between using and
> >>>>> not using
> >>>>>>> RFC5107 behavior.  The use of RFC5107 will allow the 
> MAG to do 
> >>>>>>> normal forwarding.  If not, the MAG will need to
> >> inspect on the
> >>>>>>> {destination IP address, protocol, port} tuple to trap
> >> the DHCP
> >>>>>>> packets destined to the server.
> >>>>>>
> >>>>>> No this is optional. The requirement for the MAG to be on
> >>>>> the path for
> >>>>>> the DHCP messages is optional. So it does not have to do
> >>> any of the
> >>>>>> above.
> >>>>>>
> >>>>>
> >>>>> In the absence of binding revocation support and any normative 
> >>>>> requirement mandating the DHCP lease times to be
> >> identical to the
> >>>>> binding lifetimes, the MAG will need to do this to stay in
> >>> sync - I
> >>>>> think that if it falls out of sync, the impact may not
> >> be serious
> >>>>> perhaps, but I will need to think through that.
> >>>>>
> >>>>> Vidya
> >>>>>
> >>>>>> NOTE that initial DHCP request messages when the mobile
> >>>>> node attaches
> >>>>>> always go through the MAG, since it is the relay.
> >>>>>>
> >>>>>> Vijay
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Vidya
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: [e-mail]
> >>>>> [mailto:[e-mail]] On
> >>>>>>>> Behalf Of Koodli, Rajeev
> >>>>>>>> Sent: Thursday, April 09, 2009 10:51 PM
> >>>>>>>> To: [e-mail]
> >>>>>>>> Subject: Re: [netlmm] Consensus call: RFC5107 based
> >>>>> DHCP message
> >>>>>>>> intercept at MAG
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Hi Vidya,
> >>>>>>>>
> >>>>>>>> question for my clarification: why does the MAG need to
> >>>>>>> intercept DHCP
> >>>>>>>> messages?
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> -Rajeev
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> ________________________________
> >>>>>>>>
> >>>>>>>> From: [e-mail] on behalf of Narayanan, Vidya
> >>>>>>>> Sent: Thu 4/9/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
> >>>>>>>
> >>>>> _______________________________________________
> >>>>> netlmm mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>>>
> >>>> _______________________________________________
> >>>> netlmm mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/netlmm
> >>>
> >>>
> >>
> 
>