2012-06-04 16:22, Maoke: > > > 2012/6/4 Rémi Després <[email protected]> > Maoke, > Please see comments inline. > > 2012-06-04 04:35, Maoke: > >> sorry for the late reply. >> >> 2012/5/23 Simon Perreault <[email protected]> >> (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). > > Right. > But these protocols require communicating nodes to know how many routers 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.
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. > 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. > > > > In this regard, 4rd doesn't introduce a new constraint (AFAIK). > > >> 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. > > > There is no intent to claim that "intermediate tools of operation can work as > in translation". > > > 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. > > 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." > > > 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.) > > >> 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. > > 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. > > > limited checksum protection focusing on addresses. 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. > 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. 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. > > > > >> 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? > > 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. > > > > >> - 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). > > 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. > > > 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. > There are AFAIK some other compromises in MAP-T+E, but to be discussed when > we have a stabilized specification. > > >> - 4rd: > >> 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? > > > 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 >> 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) > ... 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. ;-) >> >> >> >> 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?? > > 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. > > > > >> 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. > > 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). > > > 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 > > > > >> >> >> 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 >> >> _______________________________________________ >> Softwires mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/softwires > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
