On 6/30/2015 10:54 AM, Michael Welzl wrote: > >> On 30. jun. 2015, at 19.03, Joe Touch <[email protected]> wrote: >> >> >> >> On 6/30/2015 2:17 AM, Michael Welzl wrote: >>> >>>> On 30. jun. 2015, at 01.21, Joe Touch <[email protected]> wrote: >>>> >>>> +1 >>>> >>>> On 6/29/2015 4:06 PM, joel jaeggli wrote: >>>>> ignoring for a second the question of information leakage which is >>>>> apparently intentional in this case; an icmp message is unlikley to hash >>>>> onto the same path that the offending/failed flow would have been on in >>>>> many networks. >>>> >>>> When you say "middlebox" you're opening up the set that includes NATs, >>>> and that means any message that isn't to the same address/port pair >>>> isn't likely traverse the same path. >>> >>> - "might not take the same path all the way due to ECMP" is how I'd >>> put it. What makes you say "isn't likely to traverse the same path"? >> >> If you're tracing back through other NATs, and you're on the public side >> at some point along the path, the ICMP cannot be translated. >> >> Further, if you're on the private side of a NAT with multiple IP >> addresses (e.g., CGN), again the ICMP cannot be translated. >> >> These are a property of some of the very middleboxes you're trying to >> reach, not of ECMP. >> >>>> So *at best* this might be able to contact the first middlebox it >>>> encounters, >>> >>> Not true in my office. Am I really the only one? >> >> This message can traverse from the private to the public side of any NAT >> with only one IP address, but cannot traverse into the private side of a >> NAT or from private to public of CGN. I'm guessing you're testing only >> cases where the latter doesn't happen. > > Got it now, sorry for the confusion. > So I don't really care much about the middlebox behind a NAT on the other > side - it's *my* side I care about. The usage examples in the draft refer to > talking people in my institution or at the airport where I'm sitting. I don't > expect to be (or care about being) able to talk to a middlebox far, far > away... chances are, the message is dropped long before anyway.
It's a limitation; it might be useful to explain the limitation and why the remainder is still useful. >> ... >>>> (I'm also ignoring the fact that most middleboxes don't want to admit >>>> they exist, so this might be only providing another way for them to >>>> ignore you) >>> >>> That's a strange argument: >> >> Middleboxes often want to appear invisible except for *their* purposes. >> I.e., you're sending them more information that they already ignore (and >> intend to ignore), IMO. > > Still a strange argument :-) I can send them 100 other more things that > they can ignore, how is that making anything worse? > > Could be a router, could be some administrator at the first-hop border router > of my ISP, could be a person trying to run a public network at a conference > or in an airport ... all these people I want to try to reach. Some of them > have an interest in hearing feedback which they now can't get (at an airport, > I wouldn't know who to talk to and wouldn't want to go around and ask, so why > bother - but sending a short message is really not so painful). Sure. I'm just suggesting that you're working very hard to contact someone who doesn't want to pick up the phone. I'm not sure the effort will be worth the result. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
