Subject: [Softwires] What are the claimed flaws of 4rd-U?

From: Rémi Després <[email-masked]>
Date: Mon, 2 Apr 2012 14:16:09 +0200

Hi, Congxiao,

During the Softwire meeting, you came to the mike to assert that the 4rd-U specification was known to have "flaws".

Yet, you do know that the 4rd-U specification has been reviewed by competent contributors of widely varied origin, with no identified flaw left in the draft. 

Since you have AFAIK made no previous contribution on the mailing list to justify such an assertion, would you be kind enough to explain what, in your understanding, wouldn't work in 4rd-U? 

Without that, your statement might be understood as an attempt at biasing people's understanding just before a vote (which I suppose you didn't want).

Thanks,
RD

---

From: Congxiao Bao <[email-masked]>
Date: Wed, 4 Apr 2012 10:35:20 +0800

Hi Remi,

2012/4/2 Rémi Després <[email-masked]>
> During the Softwire meeting, you came to the mike to assert that the 4rd-U specification was known to have "flaws".

Yes, I said that and I insist on saying that again today.
> Yet, you do know that the 4rd-U specification has been reviewed by competent contributors of widely varied origin, with no identified flaw left in the draft.

That's NOT true. What I can see in the mailing-list before and after
WG meeting is that many points which indicated that 4rd-U are flawed
have been raised by the MAP-E/T authors and DT members, like Maoke,
etc, and several operators. I am sorry to say that even though they
repeated the same arguments several times, you ignored their
statements and said there is no identified flaw left.

I have to say this makes the discussion in the mailing-list without
efficiency, even the conclusion is OBVIOUSLY clear.

> Since you have AFAIK made no previous contribution on the mailing list to justify such an assertion, would you be kind enough to explain what, in your understanding, wouldn't work in 4rd-U?

For my perspective, 4rd-U is not on the same level compared with MAP
for the technical maturity if we freeze the current version of MAP
Series and 4rd-U. The MAP series are the extensions of existing RFCs
and have well tested running codes, while 4rd-U redefined things in
existing RFCs and have not been tested. Per your request, I can
summarize my check list here, some have been already shown in the
mailing-list, hopefully I don’t need to repeat the same arguments
again in the future:

(1)	4rd-u tries to replace MAP-E, however, 4rd-u cannot support IPv4
option. In the case when perfect IPv4 transparency is required, MAP-E
cannot be avoided.

(2)	4rd-u tries to replace Map-T, however, 4rd-u is not compatible
with IPv4/IPv6 single translation. For the networks which also deploy
single translation, MAP-T cannot be avoided. For example, the web
caching in the IPv6 only network between BR and CEs requires single
translation mechanism, which 4rd-u cannot support. Don’t mention BIH,
if you want to combine BIH, 4rd-U is not the Unified solution as you
claimed.

(3)	4rd-u changes the IPv6 header architecture (redefine fragmentation
header extension) and IPv6 address architecture (u/g-bits), the later
conflicts with RFC4291. These are the fundamental changes, which needs
the proof from 6man. The experimental data should also be presented to
show this design is not harmful.

(4)	If 4rd-u becomes the standard, then there will be new defined
“IPv6.1” packets on the Internet (new meaning of u/g-bits, new defined
fragmentation header, new type of ICMPv6, etc, more details in (6) and
(8)), and no existing IPv6 devices can understand those packets.

(5)	4rd-u is designed to achieve better transparency compared to
MAP-T, however, it only addresses a corner case (DF=1 and MF=1) and
the experimental data indicates that there is only 10e-5% of such
packets and those packets are not representing normal traffic. The
experimental data of 4rd-u deployment should be presented to show that
your redefinition of (3) and the risk of (4), is worth bringing the
benefit of just addressing to this corner case (DF=1 and MF=1). I
don't think the corner case can make significant difference to the
user experience. Further more, can you give me the use case of that
corner case?

(6)	In order to address corner case (DF=1 and MF=1), 4rd-u always
inserts the IPv6 fragmentation header and overload the ID field (DF,
TTL, TOS). The IPv6 fragment header has been shown to cause
operational difficulties in practice due to limited firewall
fragmentation support. In addition, the packets with MF=0 and Offset=0
are "atomic fragments", this issues is under discussion in 6man and
likely requires the OS and security updates
(draft-gont-6man-ipv6-atomic-fragments-00). Furthermore, if an IPv6
packet, which contains fragmentation header and the ID has “DF set by
the definition of 4rd-U”, reaches a 4rd-U end point, it will be
translated to IPv4 packets with DF=1, and the DF transparency may be
lost. The experimental data should be presented to show this design is
not harmful.

(7)	4rd-u tries to add checksum neutral hex in the address, however,
it still cannot support new transport layer standard when NAT44 is
used.

(8)	New types of ICMPv6 defined by 4rd-u needs the update of RFC4443.
The existing IPv6 firewall cannot support it.

(9)    4rd-u tries to reinvent the wheel by defining new schemes in
IPv6, just for the IPv4 to IPv6 transition and only addresses corner
cases. I wonder if this is worth the huge cost even the technical flaw
could be removed. The lessons I learned in Behave and v6ops is that
changing IPv6 architecutre which can only be used for the IPv4 to IPv6
transition is a bad idea and harmful.

> Without that, your statement might be understood as an attempt at biasing people's understanding just before a vote (which I suppose you didn't want).

On the Friday’s meeting, I just want to speak out my own option and I
would like to say it again here: For a reasonable ISP, it pursues
simple (single) solution for sure, but FIRST of ALL, that solution
should be technically Correct. Considering both the previous
discussion in the mailing-list (before the WG meeting) and on-site
discussions before the open MIC, and the first run of concensus, I
strongly believed that the rough consensus has been reached: MAP is
superior to 4rd-U. Even for the second run of consensus, MAP still
stands out (25 to 12). Please respect those audiences on site, who
understand MAP series and 4rd-U, they raised their hands for MAP
representing their neutral technique position, which of course can not
be biased by me. Please also note that on the mailing list, many
people present their comments, that sould wait more than the hands
(without voices on the mailing list) in the meeting.

Regards,

Congxiao

>
>
> Thanks,
> RD
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Wed, 4 Apr 2012 06:04:52 +0000

dear Remi,

> Yet, you do know that the 4rd-U specification has been reviewed by
> competent contributors of widely varied origin, with no identified flaw
> left in the draft.
>

the "with no identified flaw left in the draft" is only your statement
instead of the conclusion of the competent contributors.

if the draft -06 or -07 limits the scope of 4rd-u with at least the
following constrainsts, i guess it could be better with less flaws.
- the domain having IPv6 firewalls or filters or IP/ICMP integrity
varification mechanism between CE and BR is out of scope
- the domain having IPv6 dynamic routing ttl-security mechanism is out of
scope
- simultaneously supporting single translation with using IPv4-mapped
address for native IPv6-only networks/nodes is out of scope
- supporting L4 protocol that not yet supported by NAT44 is out of scope
(even for the case where NAT44 is bypassed, like 1:1 address mapping)
- the IPv4 option transparency is out of scope, even for temporary
end-to-end usage for some reason like experiments.

were 4rd-u-06 updated with the above constraints, it is still have some
technical inconsistency. i'd love to point them out when i have seen the
scope clarification made by the authors. because the problem impact would
change when the scope is changed. (well, it is another problem if people
would like to have such a so-limited stuff)

> Since you have AFAIK made no previous contribution on the mailing list to
> justify such an assertion, would you be kind enough to explain what, in
> your understanding, wouldn't work in 4rd-U?
>
> Without that, your statement might be understood as an attempt at biasing
> people's understanding just before a vote (which I suppose you didn't want).
>

one doesn't write too much in cockfighting mails != he/she doesn't think,
listen, and analyze. on the other hand, i understand the statement (no
matter oral or written) in the venue is also considered as IETF
contribution.

do you think your statement on "no identified flaws left", ignoring the
fact that competent contributors keep arguing, is not an attempt at biasing
people's understanding in the venue?

- maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Apr 2012 09:36:26 +0200

Congxiao,

None of what follows leaves AFAIK what would be a flaw preventing operational deployments to be successful.
Yet, thank you for this clarification of your understanding.
Unless you wish to pursue, this is enough for me. 

Le 2012-04-04 à 04:35, Congxiao Bao a écrit :

> mailing-list,

> hopefully I don’t need to repeat the same arguments
> again in the future:
> 

No ISP I know justifies having two standards just because of IPv4 options.
IPv4 options have never been a requirement of Softwire stateless solutions, and shouldn't therefore be claimed to be a flaw.

> single translation, MAP-T cannot be avoided.

False.
4rd-U clearly can coexist with NAT64 and with BIH which are both single translation.
This isn't an identified flaw. 

> For example, the web
> translation mechanism, which 4rd-u cannot support.

4rd-U does support web caches AFAIK.
Unless you provide evidence of this assertion, this doesn't make an identified flaw.

> Don’t mention BIH,
> conflicts with RFC4291.

A backward-compatible extension has always been one of the approaches to make progress (in this instance, a clear and simple use of an existing escape combination and of some unused bits).
This isn't an identified flaw. 
 
> These are the fundamental changes, which needs

> (8)), and no existing IPv6 devices can understand those packets.

The draft says what needs to be said.
- No need for any IPv6.1!
- No problem with any existing IPv6 device has been identified
This isn't an identified flaw.

> benefit of just addressing to this corner case (DF=1 and MF=1).

This point isn't describing a (supposed) flaw.

> user experience. Further more, can you give me the use case of that

The benefit is a one standard instead of two (as transparent as E and as open to IPv6-only O&M as T).

> fragmentation support.

The same applies to RFC6145 when it adds a fragment header.
If this would be a flaw, it would apply also to MAP-T.

> In addition, the packets with MF=0 and Offset=0

If this would be a flaw, it would apply also to MAP-T.

> The existing IPv6 firewall cannot support it.

No new ICMPv6 type is defined AFAIK for 4rd-U.
Cannot therefore be claimed to be a flaw.

> transition is a bad idea and harmful.

This is a comment, not identification of a (supposed) flaw.

> would like to say it again here:

> For a reasonable ISP, it pursues
> should be technically Correct.

Agreed.

> Considering both the previous
> stands out (25 to 12).

I have been told 25 to 13, but in any case substantial support for both. 
Tom Taylor's initial perception does confirm that there was no rough consensus.

> Please respect those audiences on site, who
> be biased by me.

Of course, understanding MAP doesn't imply understanding also 4rd-U. 
Your comment was to disqualify 4rd-U for those who didn't know it yet. 

I respect ALL participants (but find it a duty to rectify invalid arguments, i.e. to do normal standardization work).

> Please also note that on the mailing list, many

Applies also to 4rd-U, in particular with 3 co-authors absent in the Paris meeting.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Apr 2012 09:49:37 +0200

Le 2012-04-04 à 08:04, Maoke a écrit :

> the "with no identified flaw left in the draft" is only your statement instead of the conclusion of the competent contributors. 
> 
> if the draft -06 or -07 limits the scope of 4rd-u with at least the following constrainsts, i guess it could be better with less flaws. 
> - the domain having IPv6 firewalls or filters or IP/ICMP integrity varification mechanism between CE and BR is out of scope
> - the domain having IPv6 dynamic routing ttl-security mechanism is out of scope 
> - simultaneously supporting single translation with using IPv4-mapped address for native IPv6-only networks/nodes is out of scope
> - supporting L4 protocol that not yet supported by NAT44 is out of scope (even for the case where NAT44 is bypassed, like 1:1 address mapping)
> - the IPv4 option transparency is out of scope, even for temporary end-to-end usage for some reason like experiments. 
> 
> were 4rd-u-06 updated with the above constraints, it is still have some technical inconsistency. i'd love to point them out when i have seen the scope clarification made by the authors. because the problem impact would change when the scope is changed. (well, it is another problem if people would like to have such a so-limited stuff)
> 
> 
> one doesn't write too much in cockfighting mails != he/she doesn't think, listen, and analyze. on the other hand, i understand the statement (no matter oral or written) in the venue is also considered as IETF contribution.
> 

> do you think your statement on "no identified flaws left", ignoring the fact that competent contributors keep arguing,

Keeping arguing isn' sufficient to identify a real flaw.
In all fairness, I believe that all real points you raised were covered, either by clarifications or with complements in the design, and that absence of flaws will be verified on actual implementations. 

Now, I think time has now come to calm down, and apply with the chair's announced plan before the meeting in case no single choice would emerge: have all documents published as WG drafts on experimental track.

Regards,
RD

> is not an attempt at biasing people's understanding in the venue? 
> 
> - maoke 
>  
> 
> Thanks,
> RD
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Apr 2012 12:23:50 +0200

> the "with no identified flaw left in the draft" is only your statement instead of the conclusion of the competent contributors. 

a) I believe that all co-authors of the 4rd-U proposal are competent contributors.
b) They did review the specification, and so far don't find any of the the alleged flaws.
There is nothing more intended in my statement above. 

Even after the last mail exchanges, and although some others think differently, I honestly think that none of the alleged 4rd-u flaws is effective in real world, and that any of these would prevent 4rd-U deployments to be useful and flawless.

Regards,
RD

> do you think your statement on "no identified flaws left", ignoring the fact that competent contributors keep arguing, is not an attempt at biasing people's understanding in the venue? 
> 
> - maoke 
>  
> 
> Thanks,
> RD
>

---

From: Maoke <[email-masked]>
Date: Wed, 4 Apr 2012 10:39:30 +0000

2012/4/4 Rémi Després <[email-masked]>

>> During the Softwire meeting, you came to the mike to assert that the
>> 4rd-U specification was known to have "flaws".
>>

well, sorry but i supposed i was one of the competent contributors despite
i am not an author. :P

>
> Even after the last mail exchanges, and although some others think
> differently, I honestly think that none of the alleged 4rd-u flaws is
> effective in real world, and that any of these would prevent 4rd-U
> deployments to be useful and flawless.
>
>
"not effective in real world" must be verified in practices. as we have
pointed out "DF=1/MF=1" is not effective in the real world and we have the
statistics from multiple sources.

regards,
maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 4 Apr 2012 13:47:38 +0200

2012-04-04  12:39, Maoke :
...
> "not effective in real world" must be verified in practices. as we have pointed out "DF=1/MF=1" is not effective in the real world and we have the statistics from multiple sources.

Maoke,

You lost me!
- My assertion is that, in 4rd-u-06, none of the identified flaws is "effective in real-world".
- You then answer that (in your opinion) the DF=MF=1 issue, which is *a MAP-T-limitation issue*, isn't effective in real world.
- I don't share this opinion, in particular because a Murphy's law says that what can fail will fail, BUT ABOVE ALL this isn't the subject: the subject is only alleged flaws of 4rd-U.

Regards,
RD