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

From: GangChen <[email-masked]>
Date: Wed, 14 Mar 2012 17:04:27 +0800

Hello authors,

Generally, the draft provided informative testing data and pointed the
failures cases. I guess some failures are related to implementations;
some are due to protocol inconsistency. It's better to make categories
so it's beneficial for the group identifying the workaround.

More detailed:

1. Some testing results have been shown in tables of section 4.2.
Wondering to known what reasons cause the data transmission failures
in the case of Frag. C => S on table 7.

2. I guess some statements on "dependency between IPv4 and IPv6
address" should be clarified further.

3. In table10, why is the hairpinning not supported? 4rd could do that
in hub&spoke mode between CE-CE communications. And 464XLAT adpoted
RFC 6146, which could support hairpinning as well.

BRs

Gang

---

From: Ruri Hiromi <[email-masked]>
Date: Thu, 22 Mar 2012 14:14:45 +0900

Hi Gang and all,

Thanks for your comment.

As you mentioned in the previous mail, the failures are due to
implementation or settings, not for protocol specification. So that we
will modify its description to be more clear.

Our additional comment in line;

> in the case of Frag. C => S on table 7.

IIJ who gave us 4rd implementation is still inspecting their codes but
the reason might comes from the MTU handling process.
For your reference, IIJ said they follow RFC2473 Section 7.2 for the
Path MTU function in 4rd.

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       |
        | --------------- | ----------------- | ---------------- |
        | MTU size S => C |        1280       |       1452       |
        | --------------- | ----------------- | ---------------- |
        |   Frag. S => C  |        YES        |        YES       |
        +-----------------+-------------------+------------------+

> address" should be clarified further.

Thank you for the advice. We will modify it more appropriate expression.

> RFC 6146, which could support hairpinning as well.

We think the lack of hairpinning support on the camp experiment might be
from configuration matters.

In the 4rd case, IIJ answered us that it was disabled in the
configuration and we could not evaluate hairpining function with CE-CE
communication at that time. In addition to that the 4rd configured as
mesh model.
The 464XLAT case was also caused by setting of PLAT.
Anyway specification of 4rd and 464XLAT would be satisfied with hairpinning.

We will try to give more information in detail in the draft.

We appreciate further comments.
Regards,

(2012/03/14 18:04), GangChen wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: Tina TSOU <[email-masked]>
Date: Thu, 22 Mar 2012 05:17:34 +0000

Jari has a IPv6 only experience draft before.

Sent from my iPad

---

From: Ruri Hiromi <[email-masked]>
Date: Thu, 22 Mar 2012 14:27:29 +0900

Hi Tina,

Yes we know his draft and refer in our draft.
In our draft we tried to use multiple techniques as "IPv6 only network".
 For example, we connected upstream networks using with PPPv6 tunnel and
IPv6 over ethernet. We also use different types of IPv4 connection like
464XLAT,4rd,SA46T over the IPv6 only networks. We report the differences
between them.

Regards,

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

---

From: Tina TSOU <[email-masked]>
Date: Thu, 22 Mar 2012 05:50:59 +0000

Sent from my iPad

On Mar 21, 2012, at 10:27 PM, "Ruri Hiromi" <[email-masked]> wrote:

> 464XLAT,4rd,SA46T over the IPv6 only networks.
Can the title of the I-D reflect this point precisely?
> We report the differences
> between them.
> 
> Regards,
>

---

From: GangChen <[email-masked]>
Date: Thu, 22 Mar 2012 15:01:40 +0800

Hello Ruri,

> We will make a correction at Frag. C => S in the 4rd/IPoE case on table
                                              ^^^^^^^

Still NO here? I guess that's a typo?

> 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

---

From: Ruri Hiromi <[email-masked]>
Date: Fri, 23 Mar 2012 17:34:45 +0900

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.

> 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,

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