The transport (tunnel) CAN support that kind of fragmentation.
(e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing).
If you have a working example between a Cisco IOS XE device and a
Mikrotik router, I am all ears.
Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes.
Note I am not recommending this as a best practice. I believe the
subscribers on this list are clued enough to discern that for
themselves. But in the interest of posterity, let me make that explicit.
Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...)
:-), you're a funny guy... maybe my provider and I will just get off the
Internet altogether.
Mark.
There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting
back to the TCP servers. There are also IDIOTS that deploy load balancers that
DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
back end. There are also IDOITS that rate limit PTB generation to ridiculously
low rates. One should be able to generate PTB at line rate.
Everyone that has configured mss-fix-up has contributed to misunderstanding that
you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all
the boxes you control. We need to get PTB working and unfortunately that means
that we need to stop pandering to admins who don’t know how IP is supposed to
work. ICMP is NOT optional.
If you don’t want to do PMTUD then DO NOT SEND packet bigger than the network
MTU. For IPv6 set IPV6_USE_MIN_MTU 1 on the socket. On a properly written
IP stack this will result in TCP MSS negotiation to the same value. Yes, it is
a requirement of TCP to pay attention to this as it becomes the effective MTU
of the outgoing interface even if it wasn’t explicitly written into the RFC
that defined IPV6_USE_MIN_MTU.
Mark
You're most welcome to my choir group, good sir.
Mark.
For those of us who are in the dark, "PTB" appears to refer to "Packet
Too Big" responses in ICMPv6.
Yes, some admins don't have fine-enough grain tools to block or throttle
specific types of ICMP, but that's the fault of the vendors, not the admins.
No, it is the fault of the admins. They should be making it part of the purchasing
decision if they want to filter ICMP. It’s not like selective filtering is a new idea.
It is well over 20 years old at this stage. The amount of +20 year old equipment on the
net is minimal.
That said modern OS’s don’t need other equipment to “protect" them from ICMP of any form.
We call these tunable parameters "nerd knobs".
I used to create those knobs for firewalls. My experience then (and now, with my current employer) is that admins turn every knob you give them up to eleven; there is no finesse. The only answer was, and is, to remove the knobs altogether.
(Can I join the choir too? 
admins who don’t know how IP is supposed to work.
You do realise that in "corporate world" that's more than 80% of network admins ? Some of them even make it to "audit" companies, so they can screw a company with clueful admins with their "mandatory reccomandations".
ICMP is NOT optional.
Can we make a short rule that says: For ICMP, *ALLOW* *ALL* unless you do have a very specific and motivated reason to block some types.
I would even go as far as "allow all icmp from any to any" (and if possible as the first firewall rule), but I do understand that may make some people have hives.
Not to be the wet blanket, but we've be crying about this since before I
knew what CLI meant, and it either didn't work or has gotten even worse.
That is how we ended up with all manner of hacks to work around failure
to reliably deliver PTB messages.
We've been crying about the same during the IPv6 era, and we appear to
be running the same hacks for it too. Is there any reason to expect
things to change given the continued "crying about it" approach? Just
look at what I had to (unhappily) do over the weekend :-(.
I don't have the answers yet, but just because it now ends with a "6",
doesn't mean we shall necessarily drop our IPv4 bad habits. Perhaps it's
time to consider a different approach, if we don't want to resign
ourselves to the death of ICMP as we know it, and simply talking about
what could have been had its full potential been realized.
Mark.
Not just ICMP but everything. We've designed these nice extendible
protocols, but we've configured network so that we can't extend them.
Like why is QUIC riding on UDP, instead of having its own L4 protocol
number. Because of HTTP/3 majority of Internet traffic will be UDP,
and due to its reflection potential in other applications that is not
obvious net win. We should just retire UDP with status of 'trusted
network only L4' and use something like QUIC for all untrusted L4
applications, where we've thought about issues like reflection.
I've pointed folks at this for years:
ICMP Packet Filtering v1.2
http://www.cymru.com/Documents/icmp-messages.html
---rsk
Hey Rich,
I've pointed folks at this for years:
ICMP Packet Filtering v1.2
ICMP Packet Filtering v1.2
To me this seems anti-pattern. It seems it was written on basis of
'what we know we allow, what we don't know we deny'. With assumption
that ICMP dangerous. Similarly we break IP extensibility by not
allowing IP protocols we don't know about.
There are many, hopefully obvious reasons that just because we don't
know about it, doesn't mean it's dangerous. One more obvious is, that
it may not exist yet.
To me, the correct pattern is here is to deny things you know to be
harmful and can justify it reasonably and test that justification over
time for its validity.
One particular example springs to mind, ICMP Timestamp, this allows
you to measure unidirectional latency to millisecond precision, unless
we specifically break it. It's been useful troubleshooting tool to me
in the past, saving time and money.
From: NANOG <nanog-bounces@nanog.org> On Behalf Of Saku Ytti
Hey Rich,
> I've pointed folks at this for years:
> ICMP Packet Filtering v1.2
> ICMP Packet Filtering v1.2
To me, the correct pattern is here is to deny things you know to be harmful
and can justify it reasonably and test that justification over time for its
validity.
Let me play a devil's advocate here, the above statement begs a question then, how do you know all that is harmful would you test for every possible extension and hw/sw permutation?
So there would be 3 sets (though lines might be blurred) known safe, known harmful and the biggest of them unknown unknowns.
Now as an operator of a commercial network (i.e. your customers like it mostly up) wouldn't you do a calculated risk evaluation and opt for the known safe -which you know 99% of your customers use and block the rest while pissing off the remaining 1%?
I know it sounds awful (like a calculations for vehicle safety recalls), but ...
adam
You don't know. Everything is horribly broken anyhow and if you are
not pwned, the main reason is that you're not attractive target. If
you are being targeted, you will be pwned by zero to modest budget.
Attacker budget leverage to defender is ridiculous. And ICMP won't be
the vector.
Fear is excellent marketing tool, as we can see in politics, works
every time. But I rather fix realised problems, rather than make
unprovable assumptions of actions yielding to net benefit. The
assumption here is, if we just allow ICMP types A, B and C we are
gaining in security, can we substantiate that claim at all? We can
substantiate easily that the proposed ICMP filter breaks real useful
ICMP tooling.
Still, that's certainly not panacea. See:
https://tools.ietf.org/html/rfc7872
It would seem IETF's intention is to actually move away from
ICMPv6-based PMTUD, to the extent that is possible. (RFC4821).
Thanks,
These news don't help in that direction:
https://www.theregister.co.uk/2016/06/02/cisco_warns_of_ipv6_dos_vulnerability/
(I'm not complaining about the news, but about the bugs, if you wish)
Some of the networks that completely block ICMP are shocking.
Best,
-M<
There are lots of IDIOTS out there that BLOCK ALL ICMP. That blocks PTB getting
back to the TCP servers. There are also IDIOTS that deploy load balancers that
DO NOT LOOK INSIDE ICMP messages for redirecting ICMP messages to the correct
back end. There are also IDOITS that rate limit PTB generation to ridiculously
low rates. One should be able to generate PTB at line rate.
Everyone that has configured mss-fix-up has contributed to misunderstanding that
you can block ICMP. It is time we had a flag day to REMOVE mss-fix-up from all
the boxes you control. We need to get PTB working and unfortunately that means
that we need to stop pandering to admins who don’t know how IP is supposed to
work. ICMP is NOT optional.
It would seem IETF's intention is to actually move away from
ICMPv6-based PMTUD, to the extent that is possible. (RFC4821).
Which is not a reason to not fix broken equipment and misconfigured firewalls.
The workarounds are basically there because people deploy broken equipment.
Additionally everything isn’t TCP.
Agreed. That said, it wasn't solved in 30+ years of IPv4. Do you have
hopes it will be different with IPv6?
Thanks,