Short version: In the absence of better documented evidence that
filtering of incoming ICMP PTBs is anything more
than sporadic and quickly corrected, I can't
believe what Tony wrote.
Hi Tony,
You wrote:
>> I argue against Fred Templin's position that
>> ordinary RFC1191 DF=1 Path MTU Discovery (and
>> therefore its RFC1981 IPv6 equivalent) is "busted".
>>
>> Where is the evidence that networks filtering out
>> PTB (Packet Too Big) messages is a significant
>> problem?
>
>
> This happens. Consult some operator folks, privately and quietly. Many
> enterprises blocked all inbound ICMP when DDoS attacks started happening.
So a company XX does this, and to the extent that:
1 - Any host in its network initiating a session involving "long"
packets being sent (the TCP layer or application tries to send
as long a packet as it can), where there is a lower PMTU
outside XX's network than within, on the path to the
destination host, will find RFC1191 PMTU unusable and will
therefore be unable to communicate - unless the application
backs off the packet length due to this failure.
2 - Any host outside XX's network which initiates the session
and which involves XX's host sending "long" packets will
similarly be unable to communicate unless the XX hosts have
their own, non-RFC1191 approach to reducing packet size.
It seems like 1 would be immediately noticed within XX and presumably
lead to an end to the filtering of incoming PTBs.
2 could be trickier for XX's administrators to notice, since those
who are most likely to notice it are scattered far and wide - unless
it is noticed by whoever runs the XX side of these communications.
Where is the occurrence of this documented in anything more than the
anecdotal way you describe it above? I don't see any reason why it
would always be hush-hush.
>> To the extent that any such problem exists, why
>> should this be accepted and further protocols
>> created to work around it? I think the networks
>> which do this are non-compliant with the inter-
>> working requirements of the Internet. These
>> networks should change their ways.
>
> You have the cart before the horse. Reality is not warped to fit the
> needs of the network architecture, the network architecture must be
> molded to deal with reality. The fact of the matter is that today, we
> have a hostile environment. Anything and everything that can be used to
> create an attack will be used. To protect themselves, many people will
> happily throw the baby (or at least its signaling protocol) out with the
> bathwater.
>
> As a result, ICMP is dead. Long live ICMP.
>From what you wrote, I understand you regard RFC 1191 and RFC 1981
PMTUD to be so unreliable that an alternative must be developed and
implemented on all hosts.
Assuming this problem has been around for a while, then why wasn't
there greater support for RFC 4821?
In the time the PMTUD WG existed a handful of people exchanged about
a hundred emails. A standards track RFC emerged and it is the only
thing around which can solve the problem you refer to, other than
applications backing off packet lengths themselves.
Maybe many UDP-based applications do this already - locally doing the
same thing that RFC 4821 suggests, but without sharing any
information with other packetization layers.
But TCP is a protocol which frequently is ready to send "long"
packets - as long as its local MSS allows. It is reasonable to
assume that essentially no TCP sessions today currently use RFC 4821
PMTUD, since the only recorded implementation of it is a minimal one
in the Linux kernel, which is turned off by default.
So on one hand, you are telling us this PTB filtering happens often
enough to be a significant problem and is not going to go away even
though it must be causing some noticeable communication failure for
the networks which do it.
On the other, I see there is no alternative PMTUD mechanism in use
for TCP exchanges.
Yet if what you say is true, then the large TCP-dependent subset of
Internet communications must be going to hell in a handbasket right
now, as we speak, and the only hope of fixing it is by implementing
RFC 4821 PMTUD on every host, if only for TCP.
I look around and observe that TCP always seems to work for me and
everyone I know - and these TCP sessions are frequently using the
biggest packets the RFC 1191 PMTUD-controlled stack allows.
If what you wrote is true, then why isn't there a much greater
interest in PMTUD beyond RFC 1191 / 1981? Why didn't a large number
of people work on a much better RFC 4821 than we have now - which
merely advises what should be done, without giving any framework for
how it should actually be implemented in the stack and in apps, with
the requisite API?
Even Matt Mathis http://staff.psc.edu/mathis/ writes:
MTU is still a huge bottleneck, but this project is on hold.
He seems primarily concerned with using packets longer than 1500 bytes.
I just read the archives of the MTU mailing list - 12 messages since
2005. There was only cursory mention of the filtering problem you
insist is so real and significant.
I just scanned each message in the archives of the IETF PMTUD WG:
http://www.ietf.org/mail-archive/web/pmtud/current/maillist.html
from August 2005 to its closure in 2008. I saw occasional references
to black holes (presumably due to the filtering you mention) but no
references to how prevalent this was.
Where is the evidence that PTB filtering is ever more than a
transitory, mistaken, condition?
- Robin
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
