Skip to main content

Last Call Review of draft-ietf-6man-oversized-header-chain-08

Request Review of draft-ietf-6man-oversized-header-chain
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-10-16
Requested 2013-10-03
Authors Fernando Gont , Vishwas Manral , Ron Bonica
I-D last updated 2013-10-17
Completed reviews Genart Last Call review of -08 by Peter E. Yee (diff)
Genart Telechat review of -08 by Peter E. Yee (diff)
Secdir Last Call review of -08 by Tobias Gondrom (diff)
Assignment Reviewer Tobias Gondrom
State Completed
Request Last Call review on draft-ietf-6man-oversized-header-chain by Security Area Directorate Assigned
Reviewed revision 08 (document currently at 09)
Result Ready
Completed 2013-10-17


        have reviewed this document as part of the security
        directorate's ongoing effort to review all IETF documents being
        processed by the IESG. These comments were written primarily for
        the benefit of the security area directors. Document editors and
        WG chairs should treat these comments ust like any other last
        call comments.

        This ID is Standards Track and and updates RFC 2460 such that
        the first fragment of a packet MUST contain the entire IPv6
        header chain.

        The security considerations section is good. In fact the whole
        draft's objective is to solve a potential security problem with
        super-large IPv6 header chains and enable reliable stateless
        packet filtering for IPv6.


        1. A question, less from a security, but interoperability
        perspective: is there any deplyoment data on any potential
        backwards compatibility issues with current IPv6 deployments?
        Namely are there noteworthy deployments with large IPv6 header
        chains beyond the first fragment currently in deployment? 

        2. section 5 third paragraph: 

        I wonder whether we should be more strict and replace the "MAY"
        with a "SHOULD"? 

        This would make intermediate behavior consistent with the host
        from the previous paragraph and should avoid inconsistencies
        within the network topology? 

        Best regards, Tobias