Christian Hopps <cho...@chopps.org> wrote:
> You're confusing inner and outer traffic here. When your egress
> endpoint decaps the tunnel traffic, and then that traffic won't fit on
> it's egress red link on your egress endpoint is going to send an ICMP
> too big message back to the ingress router *inside the tunnel*. This
> has nothing to do with the routers that carry the tunnel traffic.
Assuming that this ICMP "fits" inside the tunnel.
For bog-standard site to site VPNs, that mostly means that the source IP of
the ICMP has to be the red link's IP. That's hard to get right, and Linux
certainly does it wrong in my experience, using the outside IP.
For a gateway that is linking two subnets, which are NOT directly connected,
then it's even harder to get that ICMP right. This is where I think some
other signal would be better.
>> We do have mid tunnel fragmentation (with IPv4 of course). DF=0 is
>> also preferred over dropping packets which results in a blackholing
>> situation.
> Can I ask, who is providing this mid-tunnel fragmentation service for
> you? Your upstream provider, or a DFZ transit network like AT&T? I'm
> curious b/c it's surprising that anyone is providing this service
> anymore given it's an attack vector on their network. :)
Yeah, but it still happens in IPv4.
PPPoE makes it happen; the only way that it works with the bazillion banks
that have ICMP turned off (because cisco pix default configuration of 20
years ago) is because IPv4 home routers fix the MSS.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
