while we are on the topic, and you made me re-read the document. section 4: issues with terminology. call a device that walks the extension header chain something else than a router. rfc2460 definition of a router; "extension headers are not examined or processed by any node along a packet's delivery path". a switch in my book doesn't look at L3 headers. use "middlebox" or "filtering router"?
section 3: is the main justification for this work to make NAT64s function better? if so that might be a little short-sighted, by the time we've updated IPv6 implementations... perhaps use a different example than NAT64? section 5: restricting the header chain seems like an incomplete solution. doesn't a middlebox need to reassembly fragments anyway, to deal with mis-ordered fragments? at least at some point I thought BSD sent fragmented packets by sending the last fragment first. with a more idealist hat on: that extension headers are hard to parse, some consider a feature of IPv6. a feature that tries to protect the end to end Internet, i.e. that we can deploy new transport protocols and extension headers without upgrading all intermediate boxes. changing the IPv6 protocol for a flawed design (aka middleboxes), is that wise? might as well just deprecate IP fragmentation. (which I would be in favour of). and don't get me wrong, I can't imagine any use case for an extension header chain longer than 1280 bytes either. cheers, Ole -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
