A Uniform Format for IPv6 Extension Headers
RFC 6564
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Jari Arkko; former steering group member) Yes
(Ron Bonica; former steering group member) Yes
This document updates RFC 2460, but I will let Adrian hold that DISCUSS.
(Adrian Farrel; former steering group member) (was Discuss) No Objection
(Dan Romascanu; former steering group member) No Objection
(David Harrington; former steering group member) (was Discuss) No Objection
abstract: s/past/beyond/ (past can also mean previous; the intro has more context for the usage) intro: s/absolutely essential in the Internet-Draft proposing the new option with hop-by-hop behavior./absolutely essential./
(Pete Resnick; former steering group member) No Objection
(Peter Saint-Andre; former steering group member) No Objection
My colleagues have raised a well-rounded set of questions about this document. In addition, I think it could say more about the impact on interoperability and Internet operations (these issues are mentioned in the introduction but not described in detail).
(Ralph Droms; former steering group member) (was Discuss) No Objection
(Robert Sparks; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
The Gen-ART Review by Kathleen Moriarty on 4-Dec-2011 suggested some editorial changes, and the author agreed to make them. However, the changes have not been made yet.
(Sean Turner; former steering group member) (was Discuss) No Objection
1) s4: Contains the following:
Next Header 8-bit selector. Identifies the type of header
immediately following the Extension header.
Uses the same values as the IPv4 Protocol
field.
Don't you need a reference for the values? Maybe:
[IANA_IP_PARAM]
IANA, "IP Parameters",
<http://www.iana.org/assignments/ip-parameters>.
2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?
(Stephen Farrell; former steering group member) (was Discuss) No Objection
- Doesn't this update rfc 2460?
(Stewart Bryant; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection
Extension headers are sensitive to ordering, partial deployment, and other issues. I don't think the guidelines in this document mitigate these in a meaningful way (e.g. due to the fact that it remains unknown the intermediate nodes whether unrecognized extensions earlier in the chain should alter later extension header or upper layer protocol processing), HOWEVER, I don't think the guidelines are harmful either, and can see that it's desirable to have a recommended base extension header format. For some time, high-rate DPI that I have seen has used heuristics rather than actual protocol processing. I do not think adoption of the guidelines in this document will alter that, though "helping" such devices seems to be a goal for this work. It seems undesirable to me, in general, to restrict protocol formats in order to aid layer violations ... but in the case of this particular document, I believe no harm is done.