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

[Ryuji Wakikawa <[e-mail]>]

Hi Ahmad,

On 2009/04/15, at 17:36, Ahmad Muhanna wrote:

> Hi Ryuji,
>
> Just as a follow up on this topic.
>
> Under section 3.4.2, the following text describes the available  
> options
> for the MAG in order to be aware of the state of the MN IPv4  
> address. It
> reads as follows:
>
> "
>   IPv4 Home Address Renewal to the same DHCP server: (No Handover)
>
>   o  When the DHCP client goes into the DHCP RENEW STATE [RFC-2131],  
> it
>      directly unicasts DHCPREQUEST message to the DHCP server.  The
>      DHCP relay agent may not detect these unicasted DHCPREQUEST
>      messages for renewing the address.  Thus, any of the following
>      approaches can be adopted.
>
> .....
> .....
> "
>
>
> My concern here is: "Thus, any of the following approaches can be
> adopted."
> In other words, the MAG needs to ONLY implement ONE of these options.
> Right?
>
> My Question is the following: Since implementation of the "DHCP Server
> Identifier Override Sub-option" as per RFC5107 is OPTIONAL on the DHCP
> server, the DHCP server MAY ignore this sub-option.
>
> NOW: In that case, what the MAG (DHCP Relay), which implemented this
> sub-option, is supposed to do in order to be aware of the state of the
> MN IPv4 address?

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.

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