tag:blogger.com,1999:blog-23021255.post9142009530858157219..comments2019-09-15T14:10:04.239+02:00Comments on ipSpace.net: Updated: Impact of IP Fragmentation on Tunnels and EncryptionIvan Pepelnjakhttp://www.blogger.com/profile/13457151406311272386noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-23021255.post-67388503238714416682019-09-11T21:03:38.493+02:002019-09-11T21:03:38.493+02:00You asked me for a technical opinion. I did my bes...You asked me for a technical opinion. I did my best. You can’t implement it. I get that, but there’s nothing I can do about that. It’s not like RFC 1122 was published last year... and sometimes you have to decide between implementing a dirty kludge (and a performance hit in your case) or walking away from the problem.<br /><br />Honestly, after too many kludges I had to live with, I tend to walk away these days. My sanity is precious and my time on this planet is limited. I also understand that’s not an option for everyone.<br /><br />Apologize for the rant.<br />IvanIvan Pepelnjakhttps://www.blogger.com/profile/13457151406311272386noreply@blogger.comtag:blogger.com,1999:blog-23021255.post-57295891250904192202019-09-11T20:40:37.226+02:002019-09-11T20:40:37.226+02:00Change the app behavior in legacy protocol? Theore...Change the app behavior in legacy protocol? Theoretically good idea as long as you can convince the sponsor to pay for it, and the risk is accepted (the risk of changing legacy protocol deployed in thousands of Customers).<br /><br /><br />Instead decided to enforce the fragmentation &amp; reassembly on the IPIP tunnel (on both devices terminating the tunnel). DF is ignored. <br />But it wasn&#39;t so easy to do this. Some vendors do not support such feature. Sometimes you need to switch to IPSec-nul encryption and do post-encryption fragmentation (the de-fragmentation is implicit just because to decrypt the packet it needs to be de-fragmented first). And it works as long as the IPSec can be a part of your product.<br /><br />There are many such cases where the solution is driven by business factors. Real life. Usually much more complicated than we can expect.Bogdan Golabhttps://www.blogger.com/profile/12912702162710760711noreply@blogger.comtag:blogger.com,1999:blog-23021255.post-90866598478038146822019-09-11T19:39:58.807+02:002019-09-11T19:39:58.807+02:00As you&#39;re dealing with multicast and UDP, the ...As you&#39;re dealing with multicast and UDP, the only solution is to solve the problem on the application layer, worst case limiting the MTU to minimum MTU that MUST be passed by all IPv6 routers (= 1280). I don&#39;t have a better answer :(Ivan Pepelnjakhttps://www.blogger.com/profile/13457151406311272386noreply@blogger.comtag:blogger.com,1999:blog-23021255.post-79721156008173781132019-09-11T10:35:08.846+02:002019-09-11T10:35:08.846+02:00PMTUD and UDP/multicast? Should it work?
I have s...PMTUD and UDP/multicast? Should it work?<br /><br />I have such cases in my network where the IPIP tunnel reduced the MTU and the UDP/multicast packets have size of 1500 bytes...<br /><br />I wonder what is your suggestion in such case....Bogdan Golabhttps://www.blogger.com/profile/12912702162710760711noreply@blogger.com