At 10:37 PM 10/16/98 -0700, Marc Slemko wrote:
On Fri, 16 Oct 1998, I Am Not An Isp wrote:
differently than any other packet. Unless, of course, the user manually modifies the default behavior with filters or something - which can be done to any address just as easily.
That argument is so bogus that I am amazed you are trying to use it.
I was going to leave this alone, as most people were polite and at least partially rational. But you win, I'll reply.
Saying that using private addresses for links doesn't break PMTU-D if there is a MTU change just because it requires other things in place to actually break is quite irresponsible. People are clueless enough already, don't confuse them with half truths.
I am afraid that you are the one spouting factually incorrect information. I am neither responsible for your lack of clue or your filtering. The fact that you filter RFC1918 space may be admirable, but that does not mean that RFC1918 breaks PMTU.
The reality is, that for the Internet today where a large number of people filter such addresses, using private addresses does break PMTU-D. They _CAN_ put filters on any address just as easily; if I don't want traffic from you, I can filter it. If I don't want traffic from addresses that shouldn't be sending traffic or that I use internally, I will filter it. If you have a MTU change on a router using private link addresses, then the second filter implies that the first will implicitly be true anyway for at least some traffic. It is _NOT_ correct to say that filtering either your address or private address space has just the same effect.
And if I use the RBL, and you are a known spammer, I can then deduce that spamming breaks PMTU discover in much the same way. Sure, I'm just filtering your route announcement instead of your source address, but the PMTU is still not working. So, by your logic, spamming must break PMTU discovery. FACT: RFC1918 space does not break PMTU discovery. Deal with it. I've said it before and I will say it again - the combination of private policy decisions on some networks combined with the use of RFC1918 space on routers with different MTU links (thanx to Steve Gibbard for that last detail) *will* break PMTU discovery. However, if any *one* of the above three requirements are missing, PMTU will still work just fine. Any moderately intelligent person can plainly see from the above that RFC1918 address space in and of itself does *not* break PMTU discovery. I hope I've made this clear enough. If you honestly believe people are "clueless enough already", then you should be very careful not to mislead them with "half truths". Specifically, one should be careful to separate routing rules and private policies. By claiming a policy followed by some (and I'd bet not even most) providers is fact or rule, you could mislead people who are capable deducing the perfectly deterministic behavior for themselves. I would consider this act "irresponsible", if I thought you had any "responsibility" to teach these people in the first place. As for your implication that so many people on the Internet filter RFC1918 space it should just be taken for granted, I'd like to point out you obviously didn't even read the first post in this thread. The original post included a traceroute - through a well known provider - that showed RFC1918 space source addresses. Guess both the original poster and his upstream forgot to read your rules. But that's okay, lots of other providers also forgot. Of course, it's usually smaller ones like UUNET, Sprint (that I'm sure of), MCI and BBN (I believe). Sorry if I'm a bit harsh, but it simply amazes me that people will respond to an e-mail showing a traceroute with RFC1918 space and respond with "everyone filters RFC1918, you'll never see a packet sourced from there!". TTFN, patrick I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle