Re: [netlmm] IPv4 Support

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Wed, 14 March 2007 20:24 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 1HRa1F-0008Qa-Pz; Wed, 14 Mar 2007 16:24:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRa1E-0008QV-9n for netlmm@ietf.org; Wed, 14 Mar 2007 16:24:20 -0400
Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRa1C-0005FL-VR for netlmm@ietf.org; Wed, 14 Mar 2007 16:24:20 -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); Wed, 14 Mar 2007 13:24:18 -0700
Message-ID: <45F859F2.3020205@azairenet.com>
Date: Wed, 14 Mar 2007 13:24:18 -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@gmail.com>
Subject: Re: [netlmm] IPv4 Support
References: <73296.53968.qm@web84113.mail.mud.yahoo.com> <45F84C98.3080007@azairenet.com> <45F8529A.6030604@gmail.com>
In-Reply-To: <45F8529A.6030604@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 Mar 2007 20:24:18.0308 (UTC) FILETIME=[BDFE4440:01C76676]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
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

Alexandru Petrescu wrote:

>>> 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.
>>>
>>> [behcet] You mean, HA is going to cheat MN and act as if MN is dual 
>>> stack? while it is in reality not so? What?
>>
>> I don't understand your question. The mobile node that supports
>> IPv4 only will continue to use IPv4. It is not aware of the fact
>> that there is PMIPv6 being used in the network or the fact that
>> its IPv4 traffic might be tunneled over an IPv6 tunnel between
>> the MAG and the LMA.
> 
> Double-encapsulation for IPv4 Host?
> 
> Would make sense to tunnel an IPv4 packet from MN into an IPv6 tunnel 
> (between MAG and LMA) and into another IPv4 packet (the IPv6-in-IPv4 of 
> DS-MIPv6)?
> 
> If the Host is IPv4, and the network between MAG and LMA is IPv4, why 
> encapsulating with IPv6?  Sorry, I may miss something.

There is no double encapsulation. It will either be IPv4-in-IPv4
or IPv4-in-IPv6.

Vijay

> 
>>> The IPv4 home address given to the mobile node is from a shared
>>> prefix from the LMA. There is no per-MN IPv4 prefix.
>>>
>>>
>>> [behcet] draft-thaler-multilink-subnet-issues applies to IPv6 as well 
>>> as IPv4.
>>> IPv4 HoA should also be per-MN prefix based according to this draft.
>>
>> The updated document is draft-iab-multilink-subnet-issues-03.txt
>> I don't think the issues apply here, since there is no notion of
>> a tunnel from the mobile node to the home agent. There is no
>> notion of a single IPv4 subnet being shared across multiple
>> virtual tunnels (or multiple links) between the mobile node and
>> LMA.
> 
> I think this is too quick discarded...
> 
> We may have IPv4 multi-link subnet issues with the IPv6-in-IPv4 tunnels 
> between MAG and LMA (not MN).
> 
> It is not clear at all how ARP runs over the IPv4 subnet shared across 
> multiple virtual links and how multicast over it.
> 
> It may be we want to ignore these issues for fast progress though(?).
> 
>>> Besides, I don't think it is difficult to support per-MN prefixes in 
>>> IPv4, just use
>>> 10.0 addresses.
>>
>> I don't think we should use private addresses for the IPv4 home
>> addresses. It is not required.
> 
> I agree requiring private IPv4 addresses is not good to require.
> 
> 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