On 02/09/2016 10:03 PM, joel jaeggli wrote: > On 2/8/16 10:56 AM, David Borman wrote: >> >>> On Feb 8, 2016, at 12:23 PM, Warren Kumari <warren@xxxxxxxxxx> >>> wrote: >> ... >>> On Mon, Feb 8, 2016 at 9:05 AM David Borman <dab@xxxxxxxxxxxxxxxxx> >>> wrote: >> ... >>> So if you are writing an application that needs >1500 octets, use >>> an IPv6 implementation that supports >1500 octet fragmentation and >>> reassembly. >>> >>> ... but as an application writer (or, basically anyone else), I >>> have no control over the "IPv6 implementation". Even if I'm in an >>> environment where I do control the OS / model of all devices, and I >>> know they support >1500 octet, it seems like a bad idea to *rely* >>> on that. Sometime I'm going to want to change OS / add some other >>> device, be able to interact with some other system. This sounds >>> like vendor lock at its worst… >> >> If you wind up in a scenario where you get locked to a particular OS >> vendor because it’s the only one that supports IPv6 fragmentation >>> 1500 octets, then that is probably the least of your worries. I’d >> be much more worried about IPv6 fragmentation in light of Ron >> Bonica’s comment that intermediary nodes drop packets with extension >> headers, which is bad news even for fragmented packets in the >> 1280-1500 range. > > For those of us with ecmp load balancing the challenge of associating a > fragement with the rest of the flow are also a problem. In my own case I > can engineer circumstances where I should never receive such a fragment, > so I can safely drop them anyway but I doubt everyone has that luxury. Google does, too, don't they? -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492