Seems to me that we might be misreading the original proposal. There are two ways to read it: 1) In future all Internet routing gear MUST NOT fragment IP packets. 2) Take fragmentation out of the endpoint stack. It seems to me that these are very different proposals. I fully endorse the first if we add the caveat 'except to support legacy, non jumbo frame capable links'. When those limits were set, I was programming a machine with 32K of memory. The second is obviously premature. But we could move the description of fragmentation from being a 'current feature' to a 'legacy support' issue. Didn't we have a presentation on 'sane ways to create TCP like things atop UDP' in an IETF plenary a couple of meetings back? We seem to be something of a prisoner of the 1980s era Ethernet spec. I am pretty sure that most of the equipment I buy is capable of doing jumbo packets. But quite a few of them turn out to require jumbo packets to be turned on by hand. The ability to consistently support 64KB packets and thus high throughput is potentially one of the main selling points for IPv6. I don't believe in trying to persuade people to move to IPv6 through differences in function. It will be a decade minimum before I consider making use of an IPv6 feature not supported in IPv4 in an application protocol. Performance is something else, I will encourage people to upgrade to get faster performance. Given all the sprockets, widgets and doo-dahs in the IPv6 spec, I am pretty sure that it should be possible to get it to correctly negotiate use of jumbo frames in an environment where fragmentation might occur on the path and react accordingly. So this is really a problem of UDP. And there I see three categories of application: 1) DNS - is in a class of its own due to its function as the Internet discovery protocol. 2) 'Can't help' - there are many many UDP applications today that have all dealt with fragmentation in their own idiosyncratic ways. 3) 'Right way to use UDP' - a new specification describing a 'right' way to use UDP to get TCP like features in a NAT compatible, etc fashion could provide value. I have been coding the past 6 months and doing little else. What happened to that UDP proposal?