Re: [netlmm] IPv4 Support

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Mon, 16 April 2007 18:58 UTC

Return-path: <netlmm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWOt-0003bx-3e; Mon, 16 Apr 2007 14:58:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdWOs-0003Xa-9l for netlmm@ietf.org; Mon, 16 Apr 2007 14:58:06 -0400
Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdWOr-0004uw-59 for netlmm@ietf.org; Mon, 16 Apr 2007 14:58:06 -0400
Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 11:58:04 -0700
Message-ID: <4623C73C.4030500@azairenet.com>
Date: Mon, 16 Apr 2007 11:58:04 -0700
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Alexandru Petrescu <alexandru.petrescu@motorola.com>, Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: [netlmm] IPv4 Support
References: <198227.99752.qm@web84105.mail.mud.yahoo.com> <45F6DEA1.5060008@piuha.net> <45F6E96E.4000402@gmail.com> <45F6F49F.4050405@azairenet.com> <45F6F650.9010709@gmail.com> <45F6F807.4050909@azairenet.com> <45F6FB38.8090509@gmail.com> <D4AE20519DDD544A98B3AE9235C8A4C2900A35@moe.corp.azairenet.com>
In-Reply-To: <D4AE20519DDD544A98B3AE9235C8A4C2900A35@moe.corp.azairenet.com>
Content-Type: multipart/mixed; boundary="------------020203040209080706020408"
X-OriginalArrivalTime: 16 Apr 2007 18:58:04.0764 (UTC) FILETIME=[29F3D9C0:01C78059]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6a817af60e4281a101681ecb646dffff
Cc: netlmm@ietf.org
X-BeenThere: netlmm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NETLMM working group discussion list <netlmm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/netlmm>
List-Post: <mailto:netlmm@ietf.org>
List-Help: <mailto:netlmm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>, <mailto:netlmm-request@ietf.org?subject=subscribe>
Errors-To: netlmm-bounces@ietf.org

Hi Alex, I realized I never got back to you on this. Here is a
call flow for this. I haven't show the DHCP server in the call
flow.

Lets check if we are all on the same page on this topic.

Vijay

Vijay Devarapalli wrote:
> Hi Alex,
> 
> Instead of trying to answer your email point-by-point we 
> will try to put out a call flow for this.
> 
> Vijay
> 
>> -----Original Message-----
>> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] 
>> Sent: Tuesday, March 13, 2007 12:28 PM
>> To: Vijay Devarapalli
>> Cc: Alexandru Petrescu; Behcet Sarikaya; Jari Arkko; netlmm@ietf.org
>> Subject: Re: [netlmm] IPv4 Support
>>
>> Vijay Devarapalli wrote:
>>> Alexandru Petrescu wrote:
>>>> Vijay Devarapalli wrote:
>>>>> Hello Alex and Behcet,
>>>>>
>>>>> draft-sgundave-mip6-proxymip6-02 also provides support for an
>>>>> IPv4-only mobile node. The mobile node need not have a dual
>>>>> stack. See section 5.6.
>>>>>
>>>>> The IPv4 home address given to the mobile node is from a shared
>>>>> prefix from the LMA. There is no per-MN IPv4 prefix.
>>>>  >
>>>>> Shared prefix is out of scope currently only for IPv6 addresses
>>>>> for the mobile node.
>>>> So can one say PMIPv6 does shared-prefix for IPv4 but 
>> prefix-per-MN 
>>>> for IPv6?
>>> Yes. That is what is assumed in 
>> draft-sgundave-mip6-proxymip6-02 currently.
>>>>> The MAG gets the IPv4 address for the mobile node from the LMA
>>>>> using Proxy BU/Proxy BAck messages. After that the address is
>>>>> assigned to the mobile node using DHCP.
>>>> How does  DHCP implementation on MAG know to _not_ do DHCP?
>>> I don't understand this question.
>> Well who does DHCP DISCOVER?  MN.  Who does DHCP ACK?  MAG.
>>
>> How does MAG know to _not_ relay the DISCOVER to DHCP Server and do 
>> P-BU/BAck instead?  Is that a DHCP modification?  Shouldn't 
>> that be made 
>> clear that PMIPv6 requires DHCP modifications?
>>
>>>> This is what you imply: LMA gets DHCP request and then obtains the 
>>>> IPv4 address with PBU/PBAck.
>>> The DHCP request does not go to the LMA. Only upto the MAG. Proxy 
>>> BU/Proxy BAck is used between the MAG and the LMA.
>> How does MAG _know_ to _not_ send the DHCP Request received 
>> from MN?  A 
>> DHCP implementation _does_ forward the DHCP Request.  Provided it's a 
>> DHCP Relay, of course.  I hope both you and me assume the MAG 
>> is a DHCP 
>> Relay.
>>
>> Besides, it's not the DHCP Request that MAG receives first, it's the 
>> DHCP DISCOVER.  It's upon DHCP DISCOVER that MAG should act, not upon 
>> DHCP Request.
>>
>> Alex
>>
>>
>> ______________________________________________________________________
>> This email has been scanned by the MessageLabs Email Security System.
>> For more information please visit http://www.messagelabs.com/email 
>> ______________________________________________________________________
>>
> 
> _______________________________________________
> netlmm mailing list
> netlmm@ietf.org
> https://www1.ietf.org/mailman/listinfo/netlmm

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm