Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
 by megatron.ietf.org with esmtp (Exim 4.43)
 id 1FeUIK-000691-3m; Fri, 12 May 2006 05:50:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
 by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUII-00068w-8U
 for nemo@ietf.org; Fri, 12 May 2006 05:50:46 -0400
Received: from motgate8.mot.com ([129.188.136.8])
 by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUIG-0000Rn-Vy
 for nemo@ietf.org; Fri, 12 May 2006 05:50:46 -0400
Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134])
 by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4CA7tN2007418;
 Fri, 12 May 2006 03:07:55 -0700 (MST)
Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8])
 by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4C9ok2V013899;
 Fri, 12 May 2006 04:50:46 -0500 (CDT)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117])
 by zfr01srv02.crm.mot.com (Postfix) with ESMTP
 id 46E27865980; Fri, 12 May 2006 11:50:40 +0200 (CEST)
Message-ID: <44645A70.5090301@motorola.com>
Date: Fri, 12 May 2006 11:50:40 +0200
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Keiichi SHIMA <keiichi@iijlab.net>
Subject: Re: [nemo] NEMOv4 vs DS-MIPv6
References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com>	<44638A03.4060905@motorola.com>
 <20060512.103908.119810004.keiichi@iijlab.net>
In-Reply-To: <20060512.103908.119810004.keiichi@iijlab.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAQAAAAQ=
X-White-List-Member: TRUE
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com
X-BeenThere: nemo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: NEMO Working Group <nemo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nemo>,
 <mailto:nemo-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nemo@ietf.org>
List-Help: <mailto:nemo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nemo>,
 <mailto:nemo-request@ietf.org?subject=subscribe>
Errors-To: nemo-bounces@ietf.org

Hi Keiichi,

Keiichi SHIMA wrote:
> From: Alexandru Petrescu <alexandru.petrescu@motorola.com> Subject: 
> Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 21:01:23 +0200
> 
>>>>> We don't talk about MNP tables but that doesn't mean we
>>>> don't support
>>>>> it.
>>>> I'm against silently supporting an essential data structure for
>>>>  security.
>>> => Fine, I'll add something to explain this. Feel free to suggest
>>>  text.
>> I suggest using IPv4-mapped IPv6 addresses in the Prefix Table 
>> whenever the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 
>> addresses in the NEMOv6 Prefix Table).  I am not sure though about
>>  the IPv4 MNP.  There seems to be no specification about how to use
>>  an IPv4 prefix in the v4-mapped v6 form, I've checked rfc4038 (app
>>  aspects of v6 trans) and 4291 (v6 addr arch).
> 
> If your suggestion is to write that "IPv4 MNP should be kept in 
> IPv4-mapped IPv6 address in IPv6 prefix tables", then I am against. 
> That kind of design should be implementation matter.

It may seem as implementation matter to be left out.  However, the same
draft does not leave this out and does say that the BC may store the v4
hoa address/prefix as v4-mapped:

> - If the binding update is accepted for the IPv4 home address, the 
> home agent MUST create a binding cache entry for the IPv4 home 
> address/prefix. If a single IPv4 home address were requested, it MAY
>  be stored in the IPv4-mapped IPv6 address format.

So I thought that because the BC prefers this format (v4-mapped) maybe
the Prefix Table too.

> As Vijay said in the following mail, simply saying that the prefix 
> table can keep both IPv6 and IPv4 prefixes seems enough to me.

I agree, it's simplest to write, leaving place for implementation
interpretation.

Maybe at the minimum, it is good to specify both BC and PT that IPv4
addresses and prefixes should be stored in whatever format the
implementation finds coherent (maybe v4-mapped or maybe simple 32bit
format, bot only one).

Alex



