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

[Tina TSOU <[e-mail]>]

Sent from my iPad

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

> 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.
Can the title of the I-D reflect this point precisely?
> 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.