Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01

Ruri Hiromi <hiromi@inetcore.com> Fri, 23 March 2012 08:34 UTC

Return-Path: <hiromi@inetcore.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179D21F8549 for <v6ops@ietfa.amsl.com>; Fri, 23 Mar 2012 01:34:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD7RVn-k7GwT for <v6ops@ietfa.amsl.com>; Fri, 23 Mar 2012 01:34:52 -0700 (PDT)
Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id E398721F8548 for <v6ops@ietf.org>; Fri, 23 Mar 2012 01:34:51 -0700 (PDT)
Received: from [IPv6:2403:2000:1:3:497f:3aff:dda0:b896] (unknown [IPv6:2403:2000:1:3:497f:3aff:dda0:b896]) by inc.inetcore.com (Postfix) with ESMTPSA id 88E94376932; Fri, 23 Mar 2012 17:34:50 +0900 (JST)
Message-ID: <4F6C35A5.4030105@inetcore.com>
Date: Fri, 23 Mar 2012 17:34:45 +0900
From: Ruri Hiromi <hiromi@inetcore.com>
Organization: INTEC Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: GangChen <phdgang@gmail.com>
References: <CAM+vMERyvyL4r5=vhkUYTg8D2eFSnA98a54ybtMJU6a9FUPwgA@mail.gmail.com> <4F6AB545.50904@inetcore.com> <CAM+vMEQnaziQdkOF22VNLCh-1-kU4ebWVXq4ixe_TNGb=a0Zhw@mail.gmail.com>
In-Reply-To: <CAM+vMEQnaziQdkOF22VNLCh-1-kU4ebWVXq4ixe_TNGb=a0Zhw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Mar 2012 08:34:52 -0000

Hello GangChen and all,

We are still holding to submit of -02 and if you access to the
datatracker you see NO in that part.

>>> 2. I guess some statements on "dependency between IPv4 and IPv6
>>> address" should be clarified further.
>>
>> Thank you for the advice. We will modify it more appropriate expression.
>
> It would be good if you could give more details on the list.

In 5.1 we wrote it as following;
----------
5.1.  Dependency between IPv4 and IPv6 address configuration

   In this 2nd experiment, we observed troubles due to the dependency
   between IPv4 and IPv6 address configuration.  We think, both IPv4 and
   IPv6 address configuration SHOULD work independently in a device or
   an OS.
----------

We looked some OS failed to get/use of IPv6 address if there is no IPv4
address.  Some OS tries to get IPv4 address over and over again until
local auto configured IPv4 address appeared and won't to get IPv6 address.
The OS get both IPv4 and IPv6 address if IPv4 private/global address is
available on the NIC.  We thought that kind of OS has a wrong procedure
in address configuration implementation.  Android OS is one of them but
not all the Android OS behave as above and it is presumed to be from
vendor customization.

BTW  MacOS X(10.7.0) 's Network Configuration GUI has another problem.
At the camp network we use several IPv4 addresses and switch over from
one AP to other AP, this might be a corner case but we saw a previously
used IPv4 address come up on the GUI and "ipconfig" command replied
local auto configured IPv4 address.  Renew button in the GUI does not
work correctly always displayed that previously used(wrong ranged,
abandoned) address.

Best Regards,

(2012/03/22 16:01), GangChen wrote:
> Hello Ruri,
> 
> 2012/3/22, Ruri Hiromi <hiromi@inetcore.com>:
>> Consequently the correct answer for this goes "yes".
>> We will make a correction at Frag. C => S in the 4rd/IPoE case on table
>> 7 as follows.
>>
>>         +-----------------+-------------------+------------------+
>>         |     Elements    |   4RD/PPPoE (v4)  |   4RD/IPoE (v4)  |
>>         +-----------------+-------------------+------------------+
>>         |       NAT       |       Exist       |       Exist      |
>>         | --------------- | ----------------- | ---------------- |
>>         |     Mapping     |        Bad        |       Good       |
>>         | --------------- | ----------------- | ---------------- |
>>         |    Filtering    |        Good       |       Good       |
>>         | --------------- | ----------------- | ---------------- |
>>         |       RTT       |        156        |        323       |
>>         | --------------- | ----------------- | ---------------- |
>>         | MTU size C => S |        1452       |       1452       |
>>         | --------------- | ----------------- | ---------------- |
>>         |   Frag. C => S  |         NO        |        YES       |
>                                               ^^^^^^^
> 
> Still NO here? I guess that's a typo?
> 
>>
>>
>>> 2. I guess some statements on "dependency between IPv4 and IPv6
>>> address" should be clarified further.
>>
>> Thank you for the advice. We will modify it more appropriate expression.
> 
> It would be good if you could give more details on the list.
> 
> Many thanks
> 
> Gang


-- 
---------------
Ruri Hiromi
INTEC Inc.