Subject: [Softwires] Fwd: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt

From: Maoke <[email-masked]>
Date: Tue, 10 Apr 2012 09:53:54 +0000

hi all,

i made an internet-draft discussing the semantics issue of 4rd-U. comments,
recommendations, technical discussions are welcome.

http://tools.ietf.org/html/draft-chen-softwire-4rd-u-comment-00

thanks and regards,
maoke

---------- Forwarded message ----------
From: <[email-masked]>
Date: 2012/4/10
Subject: New Version Notification for
draft-chen-softwire-4rd-u-comment-00.txt
To: [email-masked]

A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been
successfully submitted by Maoke Chen and posted to the IETF repository.

Filename:        draft-chen-softwire-4rd-u-comment
Revision:        00
Title:           A Commentary on 4rd-U Architecture and Semantics
Creation date:   2012-04-10
WG ID:           Individual Submission
Number of pages: 19

Abstract:
  4rd-U is proposed as an effort of unifying encapsulation and double
  translation solutions for the softwire of IPv4 over IPv6 domain.
  This attempt introduces new behaviors in the Internet transition
  architecture as well as semantics other than that of well-known
  Internet protocols.  This documents provides a commentary on the
  semantic changes and their impacts.

The IETF Secretariat

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Apr 2012 12:04:10 +0200

Hi, Maoke?

Thanks for this draft.
Serious technical work is the best way to progress.
I will work on it and comment after that.

Regards,
RD

Le 2012-04-10 à 11:53, Maoke a écrit :

> hi all, 
> 
> i made an internet-draft discussing the semantics issue of 4rd-U. comments, recommendations, technical discussions are welcome. 
> 
> Subject: New Version Notification for draft-chen-softwire-4rd-u-comment-00.txt
> To: [email-masked]
> 
> 
> A new version of I-D, draft-chen-softwire-4rd-u-comment-00.txt has been successfully submitted by Maoke Chen and posted to the IETF repository.
> 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 10 Apr 2012 12:10:49 -0500

Hi Maoke,

Thank you for your efforts in technical details of one specific
proposal on the table.

However, I for one think that probably it is time to concentrate on
commonalities rather than the differences. As Alain indicated, these
proposals do have a lot of common points.

Why don't (whoever) write a draft putting together all the common
points concentrating on CE to BR and abstracting out BIH, XLAT, etc.?
Such a draft can be of great value at this point, I think.

Regards,

Behcet

---

From: Tina TSOU <[email-masked]>
Date: Tue, 10 Apr 2012 18:46:27 +0000

Sent from my iPad

> Such a draft can be of great value at this point, I think.
That's MAP-D document.

---

From: Maoke <[email-masked]>
Date: Wed, 11 Apr 2012 04:28:53 +0000

hi Behcet,

2012/4/10 Tina TSOU <[email-masked]>

> > proposals do have a lot of common points.

that proposal is basically of a response to people's call for "describing
technical concerns in mind" about 4rd-U. commonality and difference is the
two sides of the same coin. if we don't understand what makes them exactly
different, we are also hard to understand how common they are. this
document is purposed in sharing such an understanding and therefore it
focuses only on the essential concerns -- the concerns regarding
architecture and protocol semantics.

> > Such a draft can be of great value at this point, I think.

yes. as Tina points out, MAP deployment draft that we are working on plays
the role of clarifying the common deployment considerations with MAP
series. thanks!

best,
maoke

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Apr 2012 16:37:24 +0900

First, thanks Maoke for publishing this document. 

It is very helpful to qualify 4rd-u that is a new type IPv4-over-IPv6 tunneling variant with several semantics changes. I think that it is very exciting proposal for all IETF participants because they shall be interested into defining new tunneling work. Once that work will have been done, I suppose that all of products of the working group shall be considered, such as RFC6333, ongoing 4over6 work and RFC5512 as BGP signaling to indicate new tunnel type for softwire mesh scenario, when we get the outcome of that work.

I can't wait that exciting future work, but not now.

cheers,
--satoru

On 2012/04/11, at 13:28, Maoke wrote:

> that proposal is basically of a response to people's call for "describing technical concerns in mind" about 4rd-U. commonality and difference is the two sides of the same coin. if we don't understand what makes them exactly different, we are also hard to understand how common they are. this document is purposed in sharing such an understanding and therefore it focuses only on the essential concerns -- the concerns regarding architecture and protocol semantics. 
>  
> yes. as Tina points out, MAP deployment draft that we are working on plays the role of clarifying the common deployment considerations with MAP series. thanks!
> 
> best,
> maoke
>  
> > Regards,
> >
> > Behcet
> >
>

---

From: Rémi Després <[email-masked]>
Date: Wed, 11 Apr 2012 14:30:35 +0200

Maoke,

Good to see that at least one who has read the 4rd-u draft still considers that technical considerations are worth working on.
Thanks.

IMHO, you did a great job to structure this (useful) discussion.
Here are quick comments/suggestions/corrections I propose: 

4.1. (M2) Rather than "simplification of L4 protocol treatment" the motivation is "Full IPv4 transparency, with never modified payloads and IPv4 fragmentation semantics"

4.1. (M4) a motivation to be added:  "No constraint on subnet-ID assignments in customer sites"

4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as ensured as in MAP-E" instead of "4rd-U argues it should be supported no matter how minor it is observed in practice".

4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they prefer, concerning DiffServ architecture, provided users cannot make the difference" instead of "4rd-U argues ToS should be kept unchanged when the packet traverses the IPv6 domain, except the ECN bits".

4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet validity of IPv4 tunneled packets, for all present and future protocols that have ports as the same place as TCP and the same checksum algorithm, without being concerned with where these protocols have their checksum fields"  instead of "it also argues checksum validity should be ensured through address in order to simplify L4 processing"

4.2. (O6)- to be added 
"UDP null checksums: [RFC6145] can be configured either to drop all IPv4 packets having null checksums, or drop only those that are fragmented. 4rd-u argues that this lack of IPv4 transparency should be avoided."

4.2. (O7)- to be added 
"Free assignment of subnet IDs:  subnet IDs that follow customer-site prefixes in native IPv6 addresses are so far freely chosen for each customer site. 4rd-u argues that this freedom should not be lost, despite the need to distinguish IPv4-originated packets from native IPv6 packets at customer-site entrances. 

4.2. after (T6) CNP and V octet, because they are related to (M4), (O6), and (07), should IMHO be considered in scope (if a new version is issued).

5.1 Impact - "Since [RFC6145] is already such that middle boxes see unfragmented IPv6 packets having fragment headers, there is no new impact" instead of "always seeing fragment header is strange to middle boxes in the IPv6 domain.  The system administrators of any middle box SHOULD be informed on the deployment of 4rd-U".

5.2 Impact - a. This, not being a concern between 4rd-u nodes, isn't needed here.

5.2 Impact - b. Not understood.

5.3 4rd-u semantics - (1) you make a VALUABLE POINT. "hop limit exceeded" should be translated to "host unreachable" as in RFC2473 (sorry for this (small) bug in 4rd-u-06). Then, the the semantics is equivalent to that of RFC2473. The only practical difference is that, if the received TTL is < 128, routing problems are detected after 127 hops within the ISP domain instead of 255 (negligible IMHO provided it is known).

5.3 Impact d. - Unless you can elaborate what you would fear, I think there is no such impact.

5.4 Impact a. - Add ", instead of protocol 4 (IPv4) in RFC2473" after "IPv6 domain MUST set all filters in middle boxes to pass protocol 1 (ICMP) as IPv6 payload in order to support 4rd-U functionality".   

5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But this integrity can be ensured at tunnel exit by checking that CNPs do preserve checksum neutrality. This can be clarified by a complement in the 4rd-u security section.

6. The statement that "double translation is also a sort of tunneling in general sense" is IMHO confusing in view of its lack of IPv4 end-to-end transparency. The statement that "It needs further investigation to ensure if 4rd-U is qualified to be called as a tunnel in the narrow sense" expresses a doubt without substance to justify it. 4rd-U only claims that IPv4 packets traverse ISP domains transparently (unless they have IPv4 options in which case the domain signals it doesn't support them).

7. Similar to encapsulation
- Add "UPP datagrams with null checksum are tunneled". 
- Delete "Middle boxes in the tunnel are unable to check if ICMPv4 message is sent to correct destination". (There is no beed for this since tunnel-exit endpoints can ensure correct destinations - see 5.4 impact c.)

7. Similar to double translation
- Add "Middle boxes can treat tunneled IPv4 packets as valid IPv6 packets for all protocols that have port positions and checksum algorithm of TCP". 
- What you mean by "without protocol layering, position of IPv4 fields are changed" is unclear to me. To be deleted or explained.
- "IPv4 options are not supported" instead of "IPv4 options are removed"

7. Never seen ...
- Add "Residual IPv4 service can be supported in sites that use subnet ID = 0".
- Fragmented packets addressed to shared-address customer sites can be tunneled without packet reassembly at domain entry."  

Kind regards,
RD

---

From: Maoke <[email-masked]>
Date: Wed, 11 Apr 2012 22:44:48 +0900

postpone other parts, but focus on the checksum issue.
2012/4/11 Rémi Després [email-masked]

>
> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4
> message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But
> this integrity can be ensured at tunnel exit by checking that CNPs do
> preserve checksum neutrality. This can be clarified by a complement in the
> 4rd-u security section.
>
>

1. this introduces another new semantics/logic of protocol stack
processing at exit CE. it is really hard to call it either IPv4 or IPv6.

2. even though this CNP works for the address integrity, unfortunately,
however, the checksum still provides integrity protection for packet length
and payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair.
they are involved either in IPv4 header checksum or in ICMPv6 checksum,
which covers the pseudo-header of IPv6. how could CNP protect these?

thanks for mentioning CNP here. i need to modify the concern for "address
integrity" to the concern for "integrity of addresses, packet length and
payload protocol type".

- maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 11 Apr 2012 17:06:13 +0200

Le 2012-04-11 à 15:44, Maoke a écrit :

> 1. this introduces another new semantics/logic of protocol stack processing at exit CE. it is really hard to call it either IPv4 or IPv6. 

How it is called is IMHO secondary, what is a fact is that it ensures address security. 
 
> 2. even though this CNP works for the address integrity,

(which was the listed point)

> unfortunately, however, the checksum still provides integrity protection for packet length and payload protocol type in both IPv4/ICMPv4 pair and IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in ICMPv6 checksum, which covers the pseudo-header of IPv6. 

> how could CNP protect these?

No way, of course.
(Are we now in the technical discussion, or still in deliberate controversy?).

> thanks for mentioning CNP here.

> i need to modify the concern for "address integrity" to the concern for "integrity of addresses, packet length and payload protocol type".

- Addresses have been covered AFAIAC.
- No test scenario I can imagine can reveal an ICMPv4 security problem concerning protocol type or packet length. (A simulated hardware failure would AFAIK be needed, and with that, many other security problems can be considered to exist.) 
=> Unless you come up with new facts, end of this subject for me.

RD

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 00:54:46 +0900

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

> unfortunately, however, the checksum still provides integrity protection
> for packet length and payload protocol type in both IPv4/ICMPv4 pair and
> IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in
> ICMPv6 checksum, which covers the pseudo-header of IPv6.
>
>
>
technical discussion results in problem understanding instead of certainly
a support for or an objection to a work politically. so i don't understand
what is the so-called "deliberate controversy" here. i suppose my draft is
written very neutral. as you raised a new solution regarding a
concern while i found it not complete, i surely need to confirm if
you would design a more comprehensive solution for that issue, and if the
already-designed mechanism has had the functionality but i was not aware of
that.

> i need to modify the concern for "address integrity" to the concern for
> "integrity of addresses, packet length and payload protocol type".
>
>
> - No test scenario I can imagine can reveal an ICMPv4 security problem
> concerning protocol type or packet length. (A simulated hardware failure
> would AFAIK be needed, and with that, many other security problems can be
> considered to exist.)
>

> => Unless you come up with new facts, end of this subject for me.

i don't think it is needed to provide new facts here, at this stage. the
test scenario is the next step. the draft is purposed on clarifying these
semantics and their direct impact. judgment on the severity of the impacts
is remained to the readers.

i don't think 4rd-u is scoped within networks with reliable L2 links, isn't
it? then, in a generic physical environment, one may think only address
checksum is enough, one may think it is not enough, one may think checksum
is anyway too weak to provide so-called protection, etc. --- all of these
sort of asserts of severity judgment are out of the scope the draft (sec 5
para 1).

fine to close this subject for me too because you have clarified "no way".
that's enough. a refined statement on this issue will appear in the
revision.

tomorrow let me clarify another.

thanks,
maoke

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 11 Apr 2012 11:18:20 -0500

On Tue, Apr 10, 2012 at 11:28 PM, Maoke <[email-masked]> wrote:
> different, we are also hard to understand how common they are. this document
> is purposed in sharing such an understanding and therefore it focuses only
> on the essential concerns -- the concerns regarding architecture and
> protocol semantics.
>
>>
> the role of clarifying the common deployment considerations with MAP series.
> thanks!
>

I would prefer calling a document that unifies both 4rd-u and MAP's 4rd.

This is what this whole Softwire work is aimed at, i.e. define 4rd protocol.

Regards,

Behcet

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 01:23:59 +0900

2012/4/12 Behcet Sarikaya <[email-masked]>

> >> On Apr 10, 2012, at 10:12 AM, "Behcet Sarikaya" <[email-masked]
> >
> >> wrote:
> >>
> >> > Hi Maoke,
> >> >
> document
> series.

unfortunately, we were on that track, as i member. - maoke

---

From: Rémi Després <[email-masked]>
Date: Wed, 11 Apr 2012 18:25:45 +0200

Le 2012-04-11 à 17:54, Maoke a écrit :

> technical discussion results in problem understanding instead of certainly a support for or an objection to a work politically. so i don't understand what is the so-called "deliberate controversy" here.

I supposed it was evident to you too that CNP cannot protect protocol and/or packet length.
Then, asking how it would do that sounded to me as a non technical question.
Sorry if this wasn't the case.  

> i suppose my draft is written very neutral.

Full of good level technical analysis, I am pleased to acknowledge.
Although I believe anyone asked to guess whether you are in favor of 4rd or MAP would easily find the answer, I can also acknowledge that the draft is neutral to a good enough extent.

> as you raised a new solution regarding a concern while i found it not complete, i surely need to confirm if you would design a more comprehensive solution for that issue, and if the already-designed mechanism has had the functionality but i was not aware of that.
> i don't think it is needed to provide new facts here, at this stage.

> the test scenario is the next step. 

OK.

> the draft is purposed on clarifying these semantics and their direct impact. judgment on the severity of the impacts is remained to the readers.

OK.

> i don't think 4rd-u is scoped within networks with reliable L2 links, isn't it?

It is scoped under the common assumption that: (1) L2 isn't reliable in that it can loose packets; (2) L2 is reliable in that it never delivers corrupted packets without corruption being detected.
AFAIK, IPv6 has been specified under this assumption.

RD

> then, in a generic physical environment, one may think only address checksum is enough, one may think it is not enough, one may think checksum is anyway too weak to provide so-called protection, etc. --- all of these sort of asserts of severity judgment are out of the scope the draft (sec 5 para 1).
>  
> fine to close this subject for me too because you have clarified "no way". that's enough. a refined statement on this issue will appear in the revision.
>

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 01:13:57 +0000

second point, on tunnel and transparency.

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

> 6. The statement that "double translation is also a sort of tunneling in
> general sense" is IMHO confusing in view of its lack of IPv4 end-to-end
> transparency.
>

limited to the definition of "a source route that circumvents conventional
routing mechanisms", IMHO, it has no business with the end-to-end
transparency and therefore not confusing with explictly specifying "in
general sense".

> The statement that "It needs further investigation to ensure if 4rd-U is
> qualified to be called as a tunnel in the narrow sense" expresses a doubt
> without substance to justify it.
>

because 4rd-u draft calls itself a "tunnel". the commentary identifies it
is surely a general-sense tunnel. the commentary tries to understand
whether it is also a narrow-sense tunnel but did not yet concluded at the
time of writing. now it looks we can conclude that 4rd-u is hard to be
called as a tunnel in the narrow sense. see below, regarding the
transparency.

> 4rd-U only claims that IPv4 packets traverse ISP domains transparently
> (unless they have IPv4 options in which case the domain signals it doesn't
> support them).
>

now we have clearified the checksum end-to-end transparency covering
payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams
in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will
continue, to reflect this understanding too, by explicitly claiming that
4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum
covering payload length and payload protocol type (instead of only
mentioning options) when the payload is ICMPv4, less than the transparency
provided by encapsulation.

commentary document will include this understanding in next revision,
without judging how severe this concern is in practice.

if no further significant dissent, this subsubject is closed.

- maoke

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 02:04:13 +0000

dear Remi,

> what is the so-called "deliberate controversy" here.
>
>

sorry but my way of asking was possibly confusing. i really thought CNP
itself couldn't do that but i worried if i missed some thing or some
straightforward possibility of easy refinement, and therefore i asked you
for confirmation.

> Although I believe anyone asked to guess whether you are in favor of 4rd
> or MAP would easily find the answer, I can also acknowledge that the draft
> is neutral to a good enough extent.
>
>
this draft is written quite earlier but i postpone its submission, trying
to avoid an impression that i attempt to bias people's selection, until the
vote was close to the end while you and others also called for technical
details about the semantics concerns in my mind. i would like to say, in
the program of the wg, i am in favor of MAP, but this favor is essentially
for now, supporting MAP as wg doc in standard track. in the term of problem
understanding, i am in favor of any serious explorations. to this extent,
facing the future, i think a neutral but pure technical commentary is
needed.

we haven't seen the wg decision. however, no matter the decision is, there
is a possibility that the work or similar exploration of 4rd-u would
continue. if the 4rd-u becomes historical, we must learn something from the
history and clearly understand why it is considered not working well
enough; if 4rd-u becomes experimental, we are obliged to tell the community
that there are something changed but we still, moderately, recommend it in
the case that these changes do not severely impact the practice. were there
no MAP, i would do the same.

that's the purpose.

thanks for understanding,
maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Apr 2012 09:43:28 +0200

Maoke,

We haven't reached common understanding on "tunnel and transparency"  yet.
Please see below.

2012-04-12  03:13, Maoke:

> 6. The statement that "double translation is also a sort of tunneling in general sense" is IMHO confusing in view of its lack of IPv4 end-to-end transparency.
> 
> limited to the definition of "a source route that circumvents conventional routing mechanisms", IMHO, it has no business with the end-to-end transparency and therefore not confusing with explictly specifying "in general sense".

Your draft says "General-sense tunnel can be a one-hop virtual link or a multi-hop participant in the delivery path", and doesn't say that it MAY MODIFY packets .
I still consider that calling "tunnel" a mechanism whereby packets may be modified (DF, ICMPv4, UDP checksums) should be avoided.
This is however a minor issue compared to (1) below.

> The statement that "It needs further investigation to ensure if 4rd-U is qualified to be called as a tunnel in the narrow sense" expresses a doubt without substance to justify it.
> 
> because 4rd-u draft calls itself a "tunnel". the commentary identifies it is surely a general-sense tunnel. the commentary tries to understand whether it is also a narrow-sense tunnel but did not yet concluded at the time of writing. now it looks we can conclude that 4rd-u is hard to be called as a tunnel in the narrow sense. see below, regarding the transparency. 

You draft says "Narrow-sense tunnel, in architecture, behaves as a one-hop virtual link".
This is the case with 4rd-u tunnels. 

>  
> 4rd-U only claims that IPv4 packets traverse ISP domains transparently (unless they have IPv4 options in which case the domain signals it doesn't support them).
> 
> now we have clearified the checksum end-to-end transparency covering payload length and payload protocol type is lost for IPv4/ICMPv4 datagrams in 4rd-u. i suggest 4rd-u draft is revised, if anyway the work will continue, to reflect this understanding too, by explicitly claiming that

> 4rd-u keeps end-to-end transparency for most of IPv4 fields but checksum covering payload length and payload protocol type (instead of only mentioning options) when the payload is ICMPv4, less than the transparency provided by encapsulation.

(1)
I already made the point that it is impossible to run a test that would show, "when the payload is ICMPv4", that a received "checksum covering payload length and payload protocol type" has been modified. 

This would need a simulated hardware failure, i.e. an open door to proving anything.

If we don't agree on this, lets first understand why.

(2)
If one would assume that packets can be corrupted at L2 without being discarded (which you seem to assume), then RFC6145 could translate a corrupted IPv4 packet having no UDP checksum into a corrupted packet having corrupted data and valid checksum. 
This would be much worse, as far as security is concerned, than ICMPv4 packets whose data would have been corrupted. 
  
> commentary document will include this understanding in next revision, without judging how severe this concern is in practice.

Before point 1 above is clarified, including what you said above in the next version of your draft would be AFAIK misleading.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Thu, 12 Apr 2012 10:33:04 +0000

> We haven't reached common understanding on "tunnel and transparency"  yet.

ok.

> Your draft says "General-sense tunnel can be a one-hop virtual link or a
> multi-hop participant in the delivery path", and doesn't say that it MAY
> MODIFY packets .
>

it doesn't say it MAY NOT.

> I still consider that calling "tunnel" a mechanism whereby packets may be
> modified (DF, ICMPv4, UDP checksums) should be avoided.
>

for the narrow-sense "tunnel", it is correct. but on the other hand, it
should be a strict "no-modification" instead of only no-modification on the
selected fields.

(well, i think we may stop this philosophical debate here because the
'general sense', 'narrow sense', ... are only my definition with "let's
call it" within this very specific draft)

> This is the case with 4rd-u tunnels.

no. with the TTL preserver, 4rd-u reaches the one-hop but not all the
virtual link behaviors. details are related to other parts and let me
postponse this topic.

> I already made the point that it is impossible to run a test that would
> show, "when the payload is ICMPv4", that a received "checksum covering
> payload length and payload protocol type" has been modified.
>

in logic,

first of all, do you also mean it is impossible to run a test that would
show any checksum has been modified unless simulated hardware failure is
introduced? and, (because it is impossible to run this), do you plan to
claim that checksum covering payload length and protocol type is actually a
useless design in ICMPv6/TCP/UDP? if you argue this, i may shut up as soon
as possible.

second, you argued no matter how it is minor, a tunnel solution should
cover it. test scenario having not repeat the checksum error doesn't mean
it never happens. it might be strange to me that you attach special
importance to the trasparency of DF=MF=1 but think checksum transparency is
not a concern.

in practice,

unfortunately, nobody can do such a conclusion to say them useless, either
nobody can say the checksum error is "minor". even on the Earth rather than
the spacecraft, there are a lot reason causing bit-errors not yet
well-protected by link layer. you might be interested in a paper published
in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=347561&bnc=1 it is
basically about TCP/UDP checksum error statistics while i believe you do
agree the understanding is also applicable for the IPv4/ICMPv6 case. the
checksum error happens with the frequency between 1/1100 ~ 1/32000, and
reaches 1/400 in some circumstances, even though the link layer CRC is
there.

to save your time, you may read
http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf instead,
for a quick understanding on why protocol needs to include its own checksum
even if the link layer has had CRC mechanism.

> If one would assume that packets can be corrupted at L2 without being
> discarded (which you seem to assume), then RFC6145 could translate a
> corrupted IPv4 packet having no UDP checksum into a corrupted packet
> having corrupted data and valid checksum.
>

ok, this talk is limited to the case where corruption happens inside in the
UDP protocol data unit.

A. native IPv4: if corrupted packet having no UDP checksum arrives at
destination, the destination anyway accepts the corrupted data;
B. acrossing IPv6 RFC6145 domain:
   B.1 if corruption happens before entering the IPv6 domain, yes,
corrupted data with valid checksum is generated, and delivered to
destination, which will accept the corrupted data;
   B.2 if corruption happens in the IPv6 domain, the translation with
checksum provides a certain extent of protection.

RFC6145 don't make B.1 worse than A while improves B.2. don't you think it
is a pros instead of a cons?

> This would be much worse, as far as security is concerned, than ICMPv4
> packets whose data would have been corrupted.
>

(on the other hand, if you would like to make a commentary for RFC6145
detailed behavior, i'd love to offer assistance as i happend to make some
humble observations on it too, but this is not the scope of this thread.)

> Before point 1 above is clarified, including what you said above in the
> next version of your draft would be AFAIK misleading.
>

in the term of stating the semantic changes with leaving judgement to
readers, i don't think there will be any misleading. i only write the fact
and the concern. some of them might be significant and severe, some of them
might be only trivial FUD. but even FUD, we are obliged to let the
community know it.

- maoke

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Apr 2012 15:52:04 +0200

2012-04-12 à 12:33, Maoke:

> for the narrow-sense "tunnel", it is correct. but on the other hand, it should be a strict "no-modification" instead of only no-modification on the selected fields. 

Are you claiming that 4rd-u can modify ICMPv4 packets that are tunneled?
If yes, could you please be kind enough provide a scenario that supports the claim?

> (well, i think we may stop this philosophical debate here because the 'general sense', 'narrow sense', ... are only my definition with "let's call it" within this very specific draft)
>  
> no. with the TTL preserver, 4rd-u reaches the one-hop but not all the virtual link behaviors. details are related to other parts and let me postponse this topic. 

OK, let's wait and see but, at least, there is no identified problem so far.

In any case, the goal of 4rd is IPv4 transparency, not support of some "virtual link" having more implications than transparency.

> first of all, do you also mean it is impossible to run a test that would show any checksum has been modified unless simulated hardware failure is introduced?

Yes, I mean that an ICMPv4 packet that is tunneled across a 4rd-u domain has its ICMP checksum unchanged.
Evidence of the contrary would be new to me.

> and, (because it is impossible to run this),

> do you plan to claim that checksum covering payload length and protocol type is actually a useless design in ICMPv6/TCP/UDP?

No.

(BTW, note that in the pdf presentation you suggest below I should read deals not only with hardware failures but also with "end-host software errors". These are out of scope for 4rd, but well in scope for UDP/TCP) 

> if you argue this, i may shut up as soon as possible. 

No need, since I haven't argued this.

(BTW, this sounds like suspicion that trying to understand what I mean, and explain why I am wrong if I am, isn't worth the effort.
I have had my share of that. Disappointed to see your seeming to join this view.)

> second, you argued no matter how it is minor, a tunnel solution should cover it. test scenario having not repeat the checksum error doesn't mean it never happens.

> it might be strange to me that you attach special importance to the trasparency of DF=MF=1 but think checksum transparency is not a concern. 

Yet, a test that shows that DF=MF=1 becomes DF=1/MF=0 after double RFC6145 translation is trivial, with 100% guaranteed success.
The same for a test that No UDP checksum is translated into a computed UDP checksum.

> in practice,
> 
> unfortunately, nobody can do such a conclusion to say them useless, either nobody can say the checksum error is "minor". even on the Earth rather than the spacecraft, there are a lot reason causing bit-errors not yet well-protected by link layer. you might be interested in a paper published in SIGCOMM'00: http://dl.acm.org/citation.cfm?id=347561&bnc=1 it is basically about TCP/UDP checksum error statistics while i believe you do agree the understanding is also applicable for the IPv4/ICMPv6 case. the checksum error happens with the frequency between 1/1100 ~ 1/32000, and reaches 1/400 in some circumstances, even though the link layer CRC is there. 
> 
> to save your time, you may read http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdf instead, for a quick understanding on why protocol needs to include its own checksum even if the link layer has had CRC mechanism. 

The only router induced errors I saw in this presentation are due to
- buggy network interfaces
- memory errors
- bus malfunctions 
All of these are hardware failures.

> ok,

> this talk is limited to the case where corruption happens inside in the UDP protocol data unit. 

Right.

> A. native IPv4: if corrupted packet having no UDP checksum arrives at destination, the destination anyway accepts the corrupted data; 

Yes, but in native IPv4 (and across 4rd-u tunnels) destination hosts know there is no checksum.

> corrupted data with valid checksum is generated, and delivered to destination, which will accept the corrupted data;

The point is that corrupted data are accepted with the supposed guarantee that they were protected by a checksum.

>    B.2 if corruption happens in the IPv6 domain, the translation with checksum provides a certain extent of protection. 

Not the subject (and in any case possible only with a supposed hardware failure).

> RFC6145 don't make B.1 worse than A while improves B.2.

- Receiving erroneous data with a checksum that assures they are valid is WORSE than receiving corrupted data with a warning that they haven't been verified.

I hope you can agree on this.

> don't you think it is a pros instead of a cons? 

Neither pro nor con, because the implied assumption of hardware failure remains AFAIAC out of scope.

> (on the other hand, if you would like to make a commentary for RFC6145 detailed behavior,

No wish to comment RFC6145 other than in the context of double translation.

> i'd love to offer assistance as i happend to make some humble observations on it too, but this is not the scope of this thread.)
>  
>   
> in the term of stating the semantic changes with leaving judgement to readers, i don't think there will be any misleading. i only write the fact and the concern. some of them might be significant and severe, some of them might be only trivial FUD. but even FUD, we are obliged to let the community know it. 

Let's then see what you will write, hopefully with preliminary consideration of the above.

Regards,
RD

---

From: Maoke <[email-masked]>
Date: Fri, 13 Apr 2012 00:35:59 +0900

a summary:

1. on the IPv6/ICMPv4 checksum issue, yes i talk about hardware failure
essentially. surely the paper i cited "also" contains other sources of
bit-error like host software. i suppose that the 4rd-u box can deal with
that before doing the header processing. regarding the IPv6/ICMPv4 checksum
issue, the main concern is hardware error in IPv6 routers.

2. on the null checksum, again the checksum because of hardware error in
IPv6 routers

(btw, IMC'07 paper argued that the DF=MF=1 was a software failure due to
poor implementation of IP stack. i really want to say software failure is
out of scope but i won't  ;-) - a btw fyi but out of service of this topic)
so the key dissent between you and me is: you think hardware failure is out
of scope but i think it is essential, because CRC in link layer is not
enough to deal with that and because a lot of error has happened before the
data is put into the physical link, and checksum is an important way to
detect such kind of failure. Stone and Partridge concluded: what TCP
checksum cannot detect are only 1 of 10 billion about, reflecting how
important the checksum is. unless 4rd-u co-authors makes out a statistics
on ICMPv6 checksum error rate is definitely below a low-enough level (e.g.,
10^-6 among ICMPv6 messages) in a test with multihop environment with high
workload and sometimes working in high temporature or in high radioactive
environment, the statement "4rd-u can keep transparency as the same as
MAP-E" would be AFAIK a misleading, at least irresponsible statement!

or, may you please gently say 4rd-u doesn't concern any environment where
IPv6 routers may have any hardware error, as you think hardware error is
out of scope. though i doubt you are really want to make a protocol for
Internet use. and i really think further discussion might be very hard, if
we are in totally different understandings regarding the most essential
assumption about the Internet.

i prepared further reply to your comments but it looks not significant now.
because all of them are related to this or that of errors, that could be
out-of-scoped by you.

- maoke

>> limited to the definition of "a source route that circumvents
>> conventional routing mechanisms", IMHO, it has no business with the
>> end-to-end transparency and therefore not confusing with explictly
>> specifying "in general sense".
>>
>>
> In any case, the goal of 4rd is IPv4 transparency, not support of some
> "virtual link" having more implications than transparency.
>
>
> introduced?
> do you plan to claim that checksum covering payload length and protocol
> type is actually a useless design in ICMPv6/TCP/UDP?
>
>
> No.
>
> (BTW, note that in the pdf presentation you suggest below I should read
> deals not only with hardware failures but also with "end-host software
> errors". These are out of scope for 4rd, but well in scope for UDP/TCP)
>
> (BTW, this sounds like suspicion that trying to understand what I mean,
> and explain why I am wrong if I am, isn't worth the effort.
> it never happens.
> it might be strange to me that you attach special importance to the
> trasparency of DF=MF=1 but think checksum transparency is not a concern.
>
>
> Yet, a test that shows that DF=MF=1 becomes DF=1/MF=0 after double RFC6145
> translation is trivial, with 100% guaranteed success.
> http://elf.cs.pub.ro/soa/res/lectures/lecture-09-tcp-crc-csum.pdfinstead, for a quick understanding on why protocol needs to include its own
> checksum even if the link layer has had CRC mechanism.
>
>
> - Receiving erroneous data with a checksum that assures they are valid is
> WORSE than receiving corrupted data with a warning that they haven't been
> verified.
>
> detailed behavior,
> i'd love to offer assistance as i happend to make some humble observations
> on it too, but this is not the scope of this thread.)
>
>
>>
>>

---

From: Maoke <[email-masked]>
Date: Fri, 13 Apr 2012 01:15:50 +0900

hi Remi,

this acknowledges the part not belonging to technical issues.
2012/4/11 Rémi Després <[email-masked]>

> Maoke,
>
> Good to see that at least one who has read the 4rd-u draft still considers
> that technical considerations are worth working on.
>
>

sorry if you mean the "at least one" is me, i don't consider the technical
considerations are worth working on but i only share understanding for
others' judgement on the worthness.

> Here are quick comments/suggestions/corrections I propose:

thanks for comments. basically the commentary is straightforward and any
statement with metaphysics should be avoided. from Mx to Tx, the author
appreciate any comments but the wording will based on what the author
understands. on the other hand, repeating what 4rd-u draft has stated in
another draft is trivial.

in details, the following comments (regarding section 4) will be reviewed
but the author won't adopt some of them, especially when it contains
metaphysics beyond the context.

thanks and regards,
maoke

>
>
>
> 4.1. (M2) Rather than "simplification of L4 protocol treatment" the
> motivation is "Full IPv4 transparency, with never modified payloads and
> IPv4 fragmentation semantics"
>
> 4.2. (O1) "4rd-U argues that IPv4 end-to-end transparency should be as
> ensured as in MAP-E" instead of "4rd-U argues it should be supported no
> matter how minor it is observed in practice".
>
> 4.2. (O1) "4rd-u leaves it to ISPs to decide which kind of tunnel they
> prefer, concerning DiffServ architecture, provided users cannot make the
> difference" instead of "4rd-U argues ToS should be kept unchanged when the
> packet traverses the IPv6 domain, except the ECN bits".
>
> 4.2. (O5) "it also argues that checksum transparency ensures IPv6 packet
> validity of IPv4 tunneled packets, for all present and future protocols
> that have ports as the same place as TCP and the same checksum algorithm,
> without being concerned with where these protocols have their checksum
> fields"  instead of "it also argues checksum validity should be ensured
> through address in order to simplify L4 processing"
>
> 4.2. (O6)- to be added
> "UDP null checksums: [RFC6145] can be configured either to drop all IPv4
> packets having null checksums, or drop only those that are fragmented.
> 4rd-u argues that this lack of IPv4 transparency should be avoided."
>
> 4.2. (O7)- to be added
> "Free assignment of subnet IDs:  subnet IDs that follow customer-site
> prefixes in native IPv6 addresses are so far freely chosen for each
> customer site. 4rd-u argues that this freedom should not be lost, despite
> the need to distinguish IPv4-originated packets from native IPv6 packets at
> customer-site entrances.
>
> 4.2. after (T6) CNP and V octet, because they are related to (M4), (O6),
> and (07), should IMHO be considered in scope (if a new version is issued).
>
>

---

From: Rémi Després <[email-masked]>
Date: Thu, 12 Apr 2012 18:36:24 +0200

Le 2012-04-12 à 18:15, Maoke a écrit :

> sorry if you mean the "at least one" is me,

> i don't consider the technical considerations are worth working on

Sorry to learn that.

> but i only share understanding for others' judgement on the worthness.
>  
>  
> Thanks.
> 
> thanks for comments. basically the commentary is straightforward and any statement with metaphysics should be avoided.

Agreed.

> from Mx to Tx, the author appreciate any comments but the wording will based on what the author understands.

Of course.

> on the other hand, repeating what 4rd-u draft has stated in another draft is trivial.
>  
> in details, the following comments (regarding section 4) will be reviewed but the author won't adopt some of them, especially when it contains metaphysics beyond the context.

Why you consider points below to be metaphysics is obscure to me.
They are believed to be operational and/or technical.

Your listing your own view of 4rd-u motivations, while refusing mine, remains your responsibility.

RD

---

From: Maoke <[email-masked]>
Date: Fri, 13 Apr 2012 01:50:11 +0900

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

> remains your responsibility.

i said "won't adopt some of them" but all will be reviewed and referenced.
the text, sure, as signed by me, is my responsibility.

- maoke