A Uniform Format for IPv6 Extension Headers
draft-ietf-6man-exthdr-06

[Ballot discuss]
- RFC 2460 says that "a receiver must not scan through a packet looking
for a particular kind of extension header and process that prior to
processing all preceeding ones" (end of p6), whereas this is saying that
we need a way to skip unknown extensions. Those seem to be in conflict.
Does that matter? If not, then saying *why* not would be good. (Simply
saying "we need DPI" doesn't answer this question IMO.) If that conflict
does matter, then what's the resolution? I don't understand how
resolving that conflict can be "future work" in any normal sense if that's
what's meant by section 6.

Document placed on today's informal IESG telechat to try to clear the remaining issues. Per my review, discusses from Ralph and Stephen should be cleared, given the new version.

[Ballot comment]
I cleared my Discuss on the basis of the RFC Editor note, but please recall that we normally also put a word in the Abstract and the Introduction to highlight "updates" relationships.

[Ballot comment]
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).

[Ballot comment]
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",
              .

2) Where do I get a ticket for the "doesn't this update 2460" bandwagon?

[Ballot discuss]
RFC 6274 examines a number of issues with IPv4 options.  Should any of those be highlighted here for IPv6 options?  I guess the one that comes to my mind is DoS attacks.  I expect the initial response to this is that this draft doesn't introduce any new security considerations, but I went and looked at the security considerations in RFC 2460 and it points to 2401 and neither discuss DoS issues.  If this is going to be the template for further options, then wouldn't it be a good idea to at least say something about how to mitigate DoS attacks with options?

[Ballot comment]
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.

[Ballot discuss]
I agree with Adrian and Ron that this document updates RFC 2460.

I also agree with Stephen that additional discussion
is needed regarding how this document
updates RFC 2460 regarding middlebox inspection
of extension headers.  That discussion might be as simple
as "middleboxes perform extension header inspection
today in contradiction of RFC 2460."  The document needs
to make the point explicitly so the IETF is aware of and can
discuss whether or not to officially sanction such behavior.

[Ballot comment]
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.

[Ballot discuss]
- RFC 2460 says that "a receiver must not scan through a packet looking
for a particular kind of extension header and process that prior to
processing all preceeding ones" (end of p6), whereas this is saying that
we need a way to skip unknown extensions. Those seem to be in conflict.
Does that matter? If not, then saying *why* not would be good. (Simply
saying "we need DPI" doesn't answer this question IMO.) If that conflict
does matter, then what's the resolution? I don't understand how
resolving that conflict can be "future work" in any normal sense if that's
what's meant by section 6.

[Ballot discuss]
- Has this gotten sufficient review? I saw no IETF LC comments at all
which is surprising for something that ostensibly changes IPv6 node
behaviour.  (I guess this is ok, but just want to check since I didn't
see much in the recent 6man archive pages at which I looked.)

- RFC 2460 says that "a receiver must not scan through a packet looking
for a particular kind of extension header and process that prior to
processing all preceeding ones" (end of p6), whereas this is saying that
we need a way to skip unknown extensions. Those seem to be in conflict.
Does that matter? If not, then saying *why* not would be good. (Simply
saying "we need DPI" doesn't answer this question IMO.) If that conflict
does matter, then what's the resolution? I don't understand how
resolving that conflict can be "future work" in any normal sense if that's
what's meant by section 6.

[Ballot comment]
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./

[Ballot comment]
abstract: s/past/beyond/
(past scan 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./

[Ballot discuss]
sec 5:
how does a receiving implementation know whether this is the extension header layout, or fragment header (what is used to differentiate these two legal header extensions?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (An uniform format for IPv6 extension headers) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'An uniform format for IPv6 extension headers'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-12-05. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  In IPv6, optional internet-layer information is encoded in separate
  headers that may be placed between the IPv6 header and the transport
  layer header.  There are a small number of such extension headers
  currently defined.  This document describes the issues that can arise
  when defining new extension headers and discusses the alternative
  extension mechanisms in IPv6.  It also provides a format for defining
  new IPv6 extension headers that would allow implementations to
  process past unknown extension headers.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-exthdr/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-exthdr/


No IPR declarations have been submitted directly on this I-D.

I have reviewed this draft. It is ready to move forward, and I have requested a last call to be initiated. In the meantime, I also had a few mostly editorial comments that you may want to take into account:

>    Also, Several existing deployed IPv6 routers and several existing

s/Several/several/

> This document intends
>    to define a standard format for IPv6 extension headers.

This document defines a standard ...

>    The base IPv6 standard [RFC2460] defines 3 extension headers (i.e.
>    Routing Header, Destination Options Header, Hop-by-Hop Options
>    Header) to be used for any new IPv6 options.  The same standard only
>    allows the creation of new Extension Headers in limited circumstances
>    [RFC2460] Section 4.6.
>
>    As noted above, the use of any option with Hop-by-Hop behaviour can
>    be problematic in the global public Internet.  So new IPv6 Extension
>    Header(s) having hop-by-hop behaviour MUST NOT be created or
>    specified.  Also, new options for the existing Hop-by-Hop Header
>    SHOULD NOT be created or specified unless no alternative is feasible.
>    Any proposal to create a new option for the existing Hop-by-Hop
>    Header MUST include a detailed explanation of why the hop-by-hop
>    behaviour is absolutely essential in the Internet-Draft proposing the
>    new option with hop-by-hop behaviour.

It might also be useful to point to RFCs 5095 and 5871 as pointing out difficulties that the design of new routing header types can bring. E.g. "Similarly, as discussed in RFCs 5095 and 5871, the design of new Routing Header types may lead to security vulnerabilities and alternatives for such designs need to be carefully assessed."

>    The scheme proposed in this document is not intended to be backward
>    compatible with all the currently defined IPv6 extension headers.  It
>    applies only to newly defined extension headers.  Specifically, the
>    fragment header predates this document and does not follow the format
>    proposed in this document.

Are there others? If yes, it would be good to mention them as well.

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Brian Haberman is the document shepherd for this document, has reviewed
this version, and believes it is ready for IESG review.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

This draft has been reviewed by many members of the 6man WG.  The
shepherd does not have concerns with the depth or breadth of these
reviews.

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No.

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

This document has strong concurrence from a small number of WG participants.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist 
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The draft passed the ID nits checks.

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

All references are in order.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

N/A.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

N/A.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        This document describes the issues that can arise when defining
        new extension headers and discusses the alternative extension
        mechanisms in IPv6.  It also provides a format for defining new
        IPv6 extension headers that would allow implementations to
        process past unknown extension headers.

    Working Group Summary
        This document was reviewed by the 6man WG and
        represents the consensus of that groups.

    Document Quality
        This document has been reviewed by the members and co-chairs
        of the 6MAN working group.