On Wed, 21 Aug 2013, Brian E Carpenter wrote: > Hi Ron, > > On 21/08/2013 01:33, Ronald Bonica wrote: > > Hi Mike, > > > > Thanks for your review of all three documents. The following is some gentle > > pushback. > > ... > > > There is no real solution to the long header problem. The best > > that we can do is to put a stake in the ground, saying that > > implementations should forward packets with header chains up to > > X bytes. There is no need to UPDATE RFC 2460, or to publish a PS > > document. A BCP is good enough. > > Architecturally, we have (I think) decided to say that header chains MUST NOT > be fragmented (this draft) and SHOULD be forwarded > (draft-ietf-6man-ext-transmit). > I'm still a bit leery about making X bytes a rule rather than a health > warning - who knows when someone might come up with a silicon-based solution > that doesn't have an X bytes limitation? A carefully worded BCP that makes > it clear that X bytes is a current engineering limit rather than an > architectural limit seems about right. > > Keeping the documents separate provides flexibility for the future, too. >
A contrary point of view is that standards-track specs, above everything else, are instructions to implementors, and other things being equal, having things in fewer places rather than more simplifies life for the implementor. I say this from the perspective of one who (many years ago) came late to the IPv4 party and found it a struggle to ferret out the necessary information. I agree that advice like "be prepared to handle header chains of at least X bytes" should be a health warning rather than a normative rule, and for that alone a BCP would be fine. But if we acknowledge that for the present, some implementations have a limit to the size of header chains that they can process, would it not be reasonable to provide guidance -- which I think would need to be in a standards track spec -- as to what kind of ICMPv6 message is appropriate if their limit is hit? (I previously suggested type = Parameter Problem, code = IPv6 header chain exceeds implementation's capacity; I neglected to say anything about the pointer; it should probably point to the first header byte that could not be processed.) All that being said, it is certainly possible to get our work done with separate documents (of whatever type). Incidentally, I could not find guidance in draft-ietf-6man-oversized-header-chain-04 as to how the set the pointer field of an ICMPv6 message sent when a first-fragment with an incomplete header chain is descarded. Left to my own devices I would probably make it point to the Payload Length in the IPv6 header, but it would be best for the spec to spell this out. Thanks, Mike Heard P.S. Thanks for keeping the pushback gentle :-) -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
