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).
>
>
> 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
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
