Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-4rd-00.txt

From: Maoke <[email-masked]>
Date: Mon, 4 Jun 2012 02:35:45 +0000

sorry for the late reply.

2012/5/23 Simon Perreault <[email-masked]>

> (Did you intend to send this to the WG?)

thanks for reminding :) i did reply but not reply-all.

>
>
> On 2012-05-22 21:38, Maoke wrote:
>
>>    My understanding: 4rd is a compromise.
>>
>>    What you gain: only one protocol to consider.
>>    What you lose: some edge cases are not supported.
>>
>>
>> that sort of statement is surely fair. but, unfortunately, 4rd document
>> seldom admits it loses something (this is why i found writing a
>> commentary was necessary). and the question is: are these *edge* cases
>> are really edge?
>>
>
> That is exactly the right question to ask.
>
>
>  a quick but incomplete list of these *edge* cases are:
>>
>> 1. routing protocols with TTL-security setting with number other than 1
>> or 255;
>>
>
> Do such protocols exist?

ebgp multihop with any possible value of ttl restriction;
other applications also possible use ttl restriction (e.g., iptable -t
mangle -m ttl).

>
>
>  2. ipv6 domain has firewalls that need to filter unknown/unexpected
>> protocols but not yet recognize ICMPv4 as IPv6 payload (at least Linux
>> ip6tables cannot filter ICMPv4; does Cisco or Juniper or Huawei can?);
>>
>
> Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a
> valid use case?

well, good question! but don't state 4rd can support intermediate tools of
operation can work as in translation, seeing the L4 payload. - such a
statement was one of the main motivation of 4rd-u. if it cannot support
intermediate operation tools working with wanted filtering regarding any
payload type, this superiority over MAP-E, AFAIK, is fake.

>
>
>  3. ipv6 routers sometimes generates bit errors in hardware or software
>> before dropping packets to NIC.
>>
>
> I fail to understand the problem here, sorry.

sorry but please read the history of

1. why Sun Microsystem enables NFS's UDP checksum after a long period of
using null checksum?
2. why higher layer checksum is still needed and how it is significant even
when link layer has contained CRC?

otherwise it would be hard to make the dialogue. sorry.

>
>  if any of the above *edge* cases actually happens, in such happening
>> *edge* cases, we still need either encapsulation or translation.
>>
>
> Since we're talking about compromise, I believe the edge case not only has
> to happen, it also has to be *important*. Meaning that we might want to
> avoid supporting some unimportant edge cases if that means simplifying the
> protocol.

good point. philosophy is the same. however, which is the simple protocol?

- MAP suite:
  A. existing encapsulation, existing translation (not anything new but
appying B);
  B. new address mapping rule;
  C. compromising DF=MF=1 edge cases (less than 10^-6 regarding importance).
- 4rd:
  A. new trans-capsulation (let me call it like that);
  B. new address mapping rule;
  C. compromising (at least)
     C1. ttl preverving for any TTL but 1 or 225 (which MAP supports with
the -E variant)
     C2. intermediate ipv6 filtering on any protocol (which MAP supports
with the -T variant)

i think the answer is obvious but i cannot help if you insist the latter is
simpler. ;-)

>
>
>     So any argument to the effect that "MAP-E|T does X and 4rd doesn't"
>>    is empty. This is expected, it's a compromise.
>>
>> some arguments are about "MAP-E|T doesn't make a confusing Y but 4rd
>> does". sorry this is not expected.
>>
>
> I believe it's also a compromise. You lose some simplicity, you gain a
> single protocol.

your above: "simplifying the protocol"; here: "you lose some simplicity".
??? have you admitted that the 4rd is less simple??

>
>
>     The argument should be: "I need 4rd to do X because ..."
>>
>> well, what is the X then? if the X is only "the number of protocol =
>> 1"... we may have a lot of ways to achieve it without the need of
>> excluding any so-called *edge* cases, without the need of introducing
>> any ugly behavior with the excuse of "compromise".
>>
>> encapsulation and translation have been the cases of loss-and-gain
>> compromises. do we need the third?
>>
>
> For example: I need 4rd to support TTL preservation for value 64 because
> I'm using routing protocol XYZ which needs it.
>

well, ttl 254, 253, 252, 251, 250, etc... are often used for eBGP multihop.
ttl 64 are sometimes used in our application facility for internal web
service.

>
> That's would be a real, justified use case. Otherwise it's just theory.

you may directly say encapsulation doing a lot things only significant in
theory. but the reality is not so. i also suggest we, moderately, not to
argue something is only a theory just because we haven't known it is really
happening somewhere unknown to us.

thanks and regards,
maoe

>
>
> Simon
> --
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Jun 2012 12:27:35 +0200

Maoke,
Please see comments inline.

2012-06-04  04:35, Maoke:

> other applications also possible use ttl restriction (e.g., iptable -t mangle -m ttl).  

Right.
But these protocols require communicating nodes to know how many routers may be traversed between them.
In this regard, 4rd doesn't introduce a new constraint (AFAIK).  

> Is filtering ICMPv4 within the 4rd domain (as opposed to its borders) a valid use case?
> 
> well, good question! but don't state 4rd can support intermediate tools of operation can work as in translation, seeing the L4 payload. - such a statement was one of the main motivation of 4rd-u.

There is no intent to claim that "intermediate tools of operation can work as in translation".

I found one place, in the Introduction, that you may find too general:
"IPv4 headers can be reversibly translated into IPv6 headers in such a way that, during IPv6 domain traversal, tunneled TCP and UDP packets are valid IPv6 packets. Thus, IPv6-only middle boxes that perform deep-packet-inspection can operate on them."
It could become:
"IPv4 headers can be reversibly translated into IPv6 headers in such a way that, during IPv6 domain traversal, UDP packets having checksums and TCP packets are valid IPv6 packets. Thus, IPv6-only middle boxes that perform deep-packet-inspection, in particular on port numbers, can operate on them." 

Thought?

> if it cannot support intermediate operation tools working with wanted filtering regarding any payload type, this superiority over MAP-E, AFAIK, is fake. 

(*) There is AFAIK no claim in the draft that, regarding "wanted filtering regarding any payload type", 4rd would be superior to MAP-E.

Besides, a clarification of the problem you see concerning this "wanted filtering regarding any payload type" would be appreciated. 
(It is clear that deploying 4rd across an IPv6 domain may imply adjustments of DPI filters if some have been configured.)

> 1. why Sun Microsystem enables NFS's UDP checksum after a long period of using null checksum?
> 2. why higher layer checksum is still needed and how it is significant even when link layer has contained CRC? 
> 

a) UDP checksums, if used, aren't disabled by 4rd. IP payloads and addresses remain protected e2e.

b) If UDP checksum aren't used (as permitted only in IPv4), the fact that addresses are not protected in tunnel headers as they are in IPv4 headers is compensated  in  4rd by the intrinsic redundancy of each tunnel-endpoint address (see (**) at the end of section 4.2). 
This address protection is also effective for ICMPv4 messages which (unlike ICMPv6 messages) don't protect addresses by their checksums.

Concerning hardware-originated errors, could you then indicate an error example that would be insufficiently detected in 4rd while sufficiently detected in MAP-T and MAP-E?

> Since we're talking about compromise, I believe the edge case not only has to happen, it also has to be *important*. Meaning that we might want to avoid supporting some unimportant edge cases if that means simplifying the protocol.
> 

At least some contributors see 4rd as simpler than MAP-T plus MAP-E, but you seem to think differently so let's take it at subjective at this point.
The main point however is that 4rd permits to have a single standardized solution, an important simplification of the global situation for vendors, operators, customers. 

> - MAP suite:
>   A. existing encapsulation, existing translation (not anything new but appying B);

Note that standard-track RFC4821 says:
 "All fragmentation SHOULD be done on the host, and all IPv4 packets, including fragments, SHOULD have the DF bit set such that they will not be fragmented (again) in the network."
This can be expected to produce many legitimate DF=MF=1.

There are AFAIK some other compromises in MAP-T+E, but to be discussed when we have a stabilized specification.

>   A. new trans-capsulation (let me call it like that);

Reversible translation, as proposed in the draft, is IMHO a better way to call it that "trans-capsulation".
Could you use it, or is there a problem?

>      C1. ttl preverving for any TTL but 1 or 225 (which MAP supports with the -E variant)
... and loses with the -T variant.

>      C2. intermediate ipv6 filtering on any protocol (which MAP supports with the -T variant) 
... and loses with the -E variant.
(This is assuming there is something significant in this point, bet see (*) above)

> 
> i think the answer is obvious but i cannot help if you insist the latter is simpler. ;-)
>  
> 
> 
> I believe it's also a compromise. You lose some simplicity, you gain a single protocol.
> 
> your above: "simplifying the protocol"; here: "you lose some simplicity". ??? have you admitted that the 4rd is less simple??

4rd may be viewed  IMHO as less simple than MAP-E alone, but it shouldn't be ignored that it does largely more. To take just  one feature, independently of those of MAP-T, 4rd BRs forward IPv4 packets on the fly, while the MAP-E specification says "If the packet is fragmented, BR should reassemble the packet". This is significant for scalability and for propagation delays.

> For example: I need 4rd to support TTL preservation for value 64 because I'm using routing protocol XYZ which needs it.
> 
> ttl 64 are sometimes used in our application facility for internal web service.

Fine.
But which example would you have where these values would be a problem with 4rd (knowing that any network decreases such values by the number of traversed routers).

Regards,
RD

> you may directly say encapsulation doing a lot things only significant in theory. but the reality is not so. i also suggest we, moderately, not to argue something is only a theory just because we haven't known it is really happening somewhere unknown to us. 
> 
> thanks and regards,
> maoe
>  
> 
> 
> Simon
> -- 
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Maoke <[email-masked]>
Date: Mon, 4 Jun 2012 23:22:04 +0900

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

> may be traversed between them.

no protocol can calculate the hops for setting the number. but human does.
in the encapsulation mode, the IPv6 provider's domain is treated as 1 hop,
which simplifies the counting.

4rd FORCES that operator MUST let the customer know the details if the
customers would like to do the hop counting even though actually the
customers don't care about such details.
MAP-T is also doing so but if operators/customers wouldn't like to have
this, MAP allows them to have the choice of MAP-E.

okay. i think i finally almost am able to understand the philosophy of 4rd.
just like the Lufthansa flight i once took. in the dinner, we had the
choice between beef and chicken and then some bad passengers claimed that
they rejected chicken because of the fear of bird diseases. in the
breakfast later, however, we had only eggs. and nobody blamed.

4rd's idea is providing only the eggs to all people, forcing them to have
to be happy but removing their trouble in choice.

> statement was one of the main motivation of 4rd-u.
>
>
>

fine. i got it. previously i understood the motivation of 4rd was making a
high quality combination of both advantages. now i know it is the
compromise for the single protocol. sorry but i was
totally misunderstanding.

> "IPv4 headers can be reversibly translated into IPv6 headers in such a way
> that, during IPv6 domain traversal, tunneled TCP and UDP packets are valid
> IPv6 packets. Thus, IPv6-only middle boxes that perform
> deep-packet-inspection can operate on them."
> It could become:
> "IPv4 headers can be reversibly translated into IPv6 headers in such a way
> that, during IPv6 domain traversal, UDP packets having checksums and TCP
> packets are valid IPv6 packets. Thus, IPv6-only middle boxes that perform
> deep-packet-inspection, in particular on port numbers, can operate on
> them."
>
>

no problem to me if it is explicitly specified what deep-inspection is ok
what is compromised.

>
>
> Thought?
>
>
> if it cannot support intermediate operation tools working with wanted
> filtering regarding any payload type, this superiority over MAP-E, AFAIK,
> is fake.
>
>
> (*) There is AFAIK no claim in the draft that, regarding "wanted filtering
> regarding any payload type", 4rd would be superior to MAP-E.
>
> Besides, a clarification of the problem you see concerning this "wanted
> filtering regarding any payload type" would be appreciated.
> (It is clear that deploying 4rd across an IPv6 domain may imply
> adjustments of DPI filters if some have been configured.)
>
>
> b) If UDP checksum aren't used (as permitted only in IPv4), the fact that
> addresses are not protected in tunnel headers as they are in IPv4 headers
> is compensated  in  4rd by the intrinsic redundancy of each tunnel-endpoint
> address (see (**) at the end of section 4.2).
> This address protection is also effective for ICMPv4 messages which
> (unlike ICMPv6 messages) don't protect addresses by their checksums.
>
>

limited checksum protection focusing on addresses.

>
>
>
> Concerning hardware-originated errors, could you then indicate an error
> example that would be insufficiently detected in 4rd while sufficiently
> detected in MAP-T and MAP-E?
>
>

checksum is improving quite effectively, in the SIGCOMM'00 paper that i
cited. i think you accept this conclusion as you so emphasize the
importance of CNP. the point is, MAP-T doesn't lose any information of the
pseudo-header-covered fields. the level of protection is as same as the
native IPv6. MAP-E keeps whole IPv4 fields and the protection level is as
same as the native IPv4 in the sense of end-to-end.

i have stated, the bit error can happen in address and surely it could
happen in any field including payload length or payload protocol
(next-header). i don't think any further detailed example is needed. it has
been clear enough.

>> Since we're talking about compromise, I believe the edge case not only
>> has to happen, it also has to be *important*. Meaning that we might want to
> At least some contributors see 4rd as simpler than MAP-T plus MAP-E, but
> you seem to think differently so let's take it at subjective at this point.
> The main point however is that 4rd permits to have a single standardized
> solution, an important simplification of the global situation for vendors,
> operators, customers.
>
>

see the above. the main point is 4rd gets rid of possible choices of people
and forces them to eat only one type of food. (i don't say it is definitely
bad but just what i don't like.) it is still very subjective.

>  "All fragmentation SHOULD be done on the host, and all IPv4 packets,
> including fragments, SHOULD have the DF bit set such that they will not be
> fragmented (again) in the network."

different understanding. host fragmentation means fragmenting the data from
upper layers before generating the IP packets, rather than generating one
and them putting it back to the stack for being fragmented. and therefore
the result will be a lot of DF=1 but MF=0 packets. this is my understanding
to the RFC4821, if wrong, please point out. (this is always welcome
regardless of the relevance to this thread).

> Could you use it, or is there a problem?

IMHO, trans-capsulation is closer to the actual behavior of 4rd. reversible
translation is a little confusing as a lot of its behavior is not
translation at all. and double translation is partially reversible too,
while 4rd, nevertheless, cannot be said "totally reversible" even it is a
little more reversible than double translation. i don't this the
trans-capsulation has anything bad meaning. scientists made Lion-Tiger very
precious and very beautiful animal. i do suggest you use the term with more
concrete meaning but i won't be over objective if you insist using
"reversible translation".

> 4rd may be viewed  IMHO as less simple than MAP-E alone, but it shouldn't
> be ignored that it does largely more. To take just  one feature,
> independently of those of MAP-T, 4rd BRs forward IPv4 packets on the fly,
> while the MAP-E specification says "If the packet is fragmented, BR should
> reassemble the packet". This is significant for scalability and for
> propagation delays.
>
>

another topic of discussion. i have little exploration on this and i have
no right to argue.

> But which example would you have where these values would be a problem
> with 4rd (knowing that any network decreases such values by the number of
> traversed routers).
>
>

surely, when i think my packets traverse your domain as tunneled, and my
customer networks contains 2 hops, i may set 252 for the valid minimum ttl.
however, 4rd makes the decrement and i will lose this packet. which is
unexpected. the value of 255 and 254 is essentially the same but 4rd forces
people have to treat them differently. and then you tell me "4rd-tunneling"
is not a commonly understood "tunnel", i get the knowledge and i may follow
4rd's semantics. but i need to think differently when i come back to the
normal world.

fine but costy. if it is worth, just for the gain of a single
specification? (very subjective, isn't it?)

i think the problems has been much discussed. further debate may become too
philosophical. let me make the commentary updated, to reflect
the significant changes between the final two versions, and you may polish
the 4rd specification further. my task is simple: to prevent the authors
missing to note the changes of semantics different from our most popular
understanding. the judgement on the impact might be subjective and the
commentary won't focus on that.

thanks for patience,
maoke

---

From: Rémi Després <[email-masked]>
Date: Mon, 4 Jun 2012 19:51:36 +0200

2012-06-04 16:22, Maoke:

> in the encapsulation mode, the IPv6 provider's domain is treated as 1 hop, which simplifies the counting.
>  
> 4rd FORCES that operator MUST let the customer know the details if the customers would like to do the hop counting even though actually the customers don't care about such details.
> MAP-T is also doing so but if operators/customers wouldn't like to have this, MAP allows them to have the choice of MAP-E.

It looks like you suggest that a customer who wants a feature of MAP-E while his ISP has chosen MAP-T, or conversely, would ask his ISP to change its choice.
Since this is of course is unrealistic, I take it as a demonstration that a single standard is much preferable.

> just like the Lufthansa flight i once took. in the dinner, we had the choice between beef and chicken and then some bad passengers claimed that they rejected chicken because of the fear of bird diseases. in the breakfast later, however, we had only eggs. and nobody blamed.
>  
> 4rd's idea is providing only the eggs to all people, forcing them to have to be happy but removing their trouble in choice.
>  
>  
>  
> fine. i got it. previously i understood the motivation of 4rd was making a high quality combination of both advantages.

Still true (significant advantages)

> now i know it is the compromise for the single protocol.

Still true (acceptable compromises)

> sorry but i was totally misunderstanding.
>  
> no problem to me if it is explicitly specified what deep-inspection is ok what is compromised. 
>  
>  
> 
> Thought?
> 
> 

Asking for more protection would AFAIK not be asking for any operational gain, only overdesign.

- UDP/TCP checksums are as efficient with 4rd tunnel traversal as without.
- ICMPv4 has its own checksum, good enough for ICMP messages
- Consequence of a corrupted null-checksum UDP datagram must be limited anyway.

> checksum is improving quite effectively, in the SIGCOMM'00 paper that i cited.

> i think you accept this conclusion as you so emphasize the importance of CNP.

I say that CNP protects against misdirections (self-redunbdncy of addresses), and permits to leave UDP/TCP layers unchanged.
No emphasis needed.

>  the point is, MAP-T doesn't lose any information of the pseudo-header-covered fields.
> the level of protection is as same as the native IPv6. MAP-E keeps whole IPv4 fields and the protection level is as same as the native IPv4 in the sense of end-to-end.
>  
> i have stated, the bit error can happen in address and surely it could happen in any field including payload length or payload protocol (next-header). i don't think any further detailed example is needed. it has been clear enough.
>  
>  
> 
> 
> see the above. the main point is 4rd gets rid of possible choices of people and forces them to eat only one type of food. (i don't say it is definitely bad but just what i don't like.) it is still very subjective.
>  
>  
> 
> 
>> - MAP suite:
> different understanding. host fragmentation means fragmenting the data from upper layers before generating the IP packets, rather than generating one and them putting it back to the stack for being fragmented. and therefore the result will be a lot of DF=1 but MF=0 packets. this is my understanding to the RFC4821, if wrong, please point out. (this is always welcome regardless of the relevance to this thread).

- You seem to say that packets with MF=1 are negligible but, if that would be so, why to have fragmentation at all in IPv6?
- The quoted sentence clearly deals with packet fragments, at layer 3, asking for their not being fragmented "again" in networks. 

> IMHO, trans-capsulation is closer to the actual behavior of 4rd. reversible translation is a little confusing as a lot of its behavior is not translation at all. and double translation is partially reversible too, while 4rd, nevertheless, cannot be said "totally reversible" even it is a little more reversible than double translation. i don't this the trans-capsulation has anything bad meaning. scientists made Lion-Tiger very precious and very beautiful animal. i do suggest you use the term with more concrete meaning but i won't be over objective if you insist using "reversible translation".

At the informal meeting on 4rd-u in Paris, someone insisted that, for him, reversible "translation" was much better than reversible "mapping". This being perceived as a problem, the terminology was changed.

Regards,
RD

> another topic of discussion. i have little exploration on this and i have no right to argue.
>  
>  
> 
> 
> surely, when i think my packets traverse your domain as tunneled, and my customer networks contains 2 hops, i may set 252 for the valid minimum ttl. however, 4rd makes the decrement and i will lose this packet. which is unexpected. the value of 255 and 254 is essentially the same but 4rd forces people have to treat them differently. and then you tell me "4rd-tunneling" is not a commonly understood "tunnel", i get the knowledge and i may follow 4rd's semantics. but i need to think differently when i come back to the normal world.
>  
> fine but costy. if it is worth, just for the gain of a single specification? (very subjective, isn't it?)
>  
> i think the problems has been much discussed. further debate may become too philosophical. let me make the commentary updated, to reflect the significant changes between the final two versions, and you may polish the 4rd specification further. my task is simple: to prevent the authors missing to note the changes of semantics different from our most popular understanding. the judgement on the impact might be subjective and the commentary won't focus on that.
>  
> thanks for patience,
> maoke
>  
>  
>  
> 
> 
> Regards,
> RD
> 
> 
> 
> 
>>  
>>