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

[Ruri Hiromi <[e-mail]>]

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,

(2012/03/22 14:17), Tina TSOU wrote:
> Jari has a IPv6 only experience draft before.
> 
> Sent from my iPad
> 
> On Mar 21, 2012, at 10:15 PM, "Ruri Hiromi" <[e-mail]> wrote:
> 
>> 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;
>>
>>> 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.
>>
>> 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       |
>>        +-----------------+-------------------+------------------+
>>
>>
>>> 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.
>>
>>> 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.
>>
>> 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:
>>> 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
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>> -- 
>> ---------------
>> Ruri Hiromi
>> INTEC Inc.
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops


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