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

[Vijay Devarapalli <[e-mail]>]

Hi Ryjji,

Ryuji Wakikawa wrote:

>> 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.
> 
> Why different DHCP server? The MAG-MAG handover is transparent to MN.
> DHCP client does not get any influence from the handover.
> I probably miss something here, can you explain this? Is this new issue?

Sure. When the new MAG uses RFC 5107 to insert itself in the path for 
all DHCP messages, the mobile node sees a different IP address for the 
DHCP server. It earlier had the old MAG as the DHCP server because the 
old MAG had also used RFC 5107 to appear as the DHCP server.

Note that the IPv4 support document currently does not require all the 
MAGs to configure a fixed IP address for the DHCP server IP address in 
the DHCP relay case. The MAGs are required to configure a fixed DHCP 
server IP address only for scenario where the DHCP server is co-located 
with the MAG. You have to now introduce this requirement even for the 
DHCP relay case to avoid the change in the DHCP server IP address as a 
result of a handover.

Vijay

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