North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: icmp rpf
- From: Mark Smith
- Date: Mon Sep 25 05:38:29 2006
On Sun, 24 Sep 2006 16:33:30 -0700 (PDT)
Mark Kent <email@example.com> wrote:
> Mark Smith wrote:
> >> The non-announcers, because they're also breaking PMTUD.
> Really? How? Remember, we're not talking about RFC1918 space,
> where there is a BCP that says we should filter it at the edge.
> We're talking about public IP space, that just doesn't happen to be
> announced outside of a particular AS.
When a router that can't shove a DF'd packet down a link because the
MTU is too small needs to create a ICMP Destination Unreachable, Packet
Too Big, Fragmentation Required, it needs to pick a source IP address
to use for that ICMP packet, which will be one of those assigned to the
router with the MTU problem (I'm fairly sure it's the IP
address assigned to the outgoing interface for this ICMP packet,
although I don't think it probably matters much). If an upstream
router, i.e. on the way back to the sender who needs to resend with a
smaller packet, is dropping these packets because they fail RPF, then
PMTUD breaks. The result might be connection timeouts at the sender, or
possibly after quite a while the sender might try smaller packets and
eventually they'll get through (I think Windows might do this). Either
way, bad end-user experience.
PMTUD as it currently works isn't ideal, as of course there isn't any
guarantee that these ICMP Dest Unreachables will get there even in a
"good" network. However, most of the time it works, where as in the
scenario you're presenting, it definately won't.
"Sheep are slow and tasty, and therefore must remain constantly
- Bruce Schneier, "Beyond Fear"