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

Ryuji Wakikawa <ryuji.wakikawa@gmail.com> Tue, 14 April 2009 16:01 UTC

Return-Path: <ryuji.wakikawa@gmail.com>
X-Original-To: netlmm@core3.amsl.com
Delivered-To: netlmm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F43B28C1BD for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 09:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14a4lf0nr8no for <netlmm@core3.amsl.com>; Tue, 14 Apr 2009 09:01:52 -0700 (PDT)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 6337C3A69DF for <netlmm@ietf.org>; Tue, 14 Apr 2009 09:00:48 -0700 (PDT)
Received: by rv-out-0506.google.com with SMTP id k40so2284822rvb.49 for <netlmm@ietf.org>; Tue, 14 Apr 2009 09:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:subject :references:message-id:content-type:content-transfer-encoding :mime-version:date:cc:x-mailer; bh=KEraBX5hoGWmTth6vQ/j53TaPcdthglEutJSTjPgNd0=; b=Ek9MinlEjLDA76pZmzaW4kCdGtrScV4YrlEkJOsuJTXqSUiGlzmvI4kLjp8CogK4F2 1g1lMKs3ya46pQBxFICGQkGwZIYvO2ST6Rb+x6vqYa8CTD8Now+D5xXD7ylEKbyrNJH4 CH41DZopnluh8vbpm4mdPDNFRGsxhoou4yyXc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc:x-mailer; b=FQ4YTHzvhpMYIbB530X/In/6Xd+vcWX2CF2oA0L4EtOlD6UV2af/Z8eITFg3YMHry5 h4y1N/LbMzUk8gREEgXypyTwClvlbWwvGi9a1qS+Z5eaXVrLCiHHvBTRkkx2m7LvatKJ WOiruMedyqCsiIGd8SY2EI+zJ6ymAnPUUsdeM=
Received: by 10.141.87.13 with SMTP id p13mr3241770rvl.229.1239724920044; Tue, 14 Apr 2009 09:02:00 -0700 (PDT)
Received: from gdhcp13.research.telcordia.com (gdhcp13.research.telcordia.com [192.4.27.238]) by mx.google.com with ESMTPS id k2sm4946154rvb.54.2009.04.14.09.01.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 14 Apr 2009 09:01:59 -0700 (PDT)
From: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
To: "Koodli, Rajeev" <rkoodli@starentnetworks.com>
In-Reply-To: <4D35478224365146822AE9E3AD4A2666035AAAB1@exchtewks3.starentnetworks.com>
References: <BE82361A0E26874DBC2ED1BA244866B9382A1F89@NALASEXMB08.na.qualcomm.com> <4D35478224365146822AE9E3AD4A2666035AAAA2@exchtewks3.starentnetworks.com> <BE82361A0E26874DBC2ED1BA244866B9382A1F91@NALASEXMB08.na.qualcomm.com> <4D35478224365146822AE9E3AD4A2666035AAAA5@exchtewks3.starentnetworks.com> <A13924FC-1FFB-4BC3-9E48-640BDE10C17B@gmail.com> <4D35478224365146822AE9E3AD4A2666035AAAB1@exchtewks3.starentnetworks.com>
Message-Id: <03ADE51E-90B1-4FE0-809D-444D48D31849@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Tue, 14 Apr 2009 12:01:48 -0400
X-Mailer: Apple Mail (2.930.3)
Cc: netlmm@ietf.org
Subject: Re: [netlmm] Consensus call: RFC5107 based DHCP message interceptat MAG
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2009 16:01:56 -0000

Hi Rajeev,

On 2009/04/14, at 11:23, Koodli, Rajeev wrote:

>
> Hi Ryuji,
>
>> MN does not send any DHCP messages at handover, because HO is
>> transparent to MN.
>> When MN renew the  IP address, the new MAG (DHCP-relay) will  
>> intercept
>> the packets with RFC5107 or promiscuous interception to sync the  
>> state
>> (verify the IPv4 leasing time. DHCP relay does not maintain any  
>> states
>> of DHCP clients).
>
> Until the MN sends any DHCP messages, the new MAG will not have the  
> consistent DHCP state then right?

The general DHCP relay does not keep any states of MN. All the states  
are managed at DHCP server.
We don't need to introduce any new states on DHCP relay for PMIP.

In PMIP, we have decided to manage the address assignment by LMA  
(PMIP) and use DHCP to deliver the assigned address to MN.
To co-operate DHCP and PMIP, we don't need any MN's actions to keep  
consistency of DHCP states.

> Also, all the MAGs should be configured with this support.

Yes, all the MAGs has to be either DHCP relay or server.

regards,
ryuji

>
>
> Thanks,
>
> -Rajeev
>
>
> regards,
> ryuji
>
>
>
>
>> Having said that, I am okay with keeping the optional mechanism, *as
>> long as*
>>
>> 1. we describe the two choices we have - LMA being the sole DHCP
>> node on the network side, which is mandatory, and the optional
>> mechanism of MAG-on-path for DHCP
>>
>> 2. Clearly state what needs to be done for handovers for the
>> optional mechanism, in addition to what is the purpose of the
>> optional mechanism (it could not be just informative).
>>
>> These have to be captured, say in separate paragraphs.
>>
>> -Rajeev
>>
>>
>>
>> ________________________________
>>
>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]
>> Sent: Thu 4/9/2009 11:11 PM
>> To: Koodli, Rajeev; netlmm@ietf.org
>> Subject: RE: [netlmm] Consensus call: RFC5107 based DHCP message
>> interceptat MAG
>>
>>
>>
>> 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.
>>
>> 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.
>>
>> Vidya
>>
>>> -----Original Message-----
>>> From: netlmm-bounces@ietf.org [mailto:netlmm-bounces@ietf.org] On
>>> Behalf Of Koodli, Rajeev
>>> Sent: Thursday, April 09, 2009 10:51 PM
>>> To: netlmm@ietf.org
>>> 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: netlmm-bounces@ietf.org on behalf of Narayanan, Vidya
>>> Sent: Thu 4/9/2009 9:48 PM
>>> To: netlmm@ietf.org
>>> 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
>>> netlmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>>
>>>
>>> _______________________________________________
>>> netlmm mailing list
>>> netlmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netlmm
>>
>>
>> _______________________________________________
>> netlmm mailing list
>> netlmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/netlmm
>
>
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm