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

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

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