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

[Ruri Hiromi <[e-mail]>]

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.