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

[Tina TSOU <[e-mail]>]

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