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. 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". 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.) > 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. 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? > 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. > - 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. 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? > 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. > 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). 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
