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. 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. now i know it is the compromise for the single protocol. 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. > > > > 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. > > > > 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). > > > 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". > 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
