IPv6 Flow Label Specification
draft-ietf-6man-flow-3697bis-07

[Ballot comment]
After discussion with the authors/editors and with the TSVDIR, it appears this field is unlikely to be used for any other purpose, and this usage is the originally intended usage, so I have cleared.

[Ballot comment]
There is no mention of the fact that individual nodes in a network are free to implement different algorithms without impacting the interoperability or function of the network.

[Ballot comment]
Ditto for this:

Richard: Also, purely from a terminology perspective, I found the
phrase "unintended service" confusing and less accurate than
the "better service" phrase used in RFC 3697.  It might be
better to spell this out: " ... an adversary may be able to
obtain a class of service that the network did not intend to
provide ... "

Brian: Agreed.

[Ballot discuss]
I don't think the point made by Richard Barnes' made it in the last version:

Richard:

Given the risks
that this document discusses, it might be worth considering a
recommendation that networks SHOULD NOT make resource
allocation decisions based on flow labels without some
external means of assurance.  Or some similar warning against
making resource decisions on a completely unsecured field.


Brian:

Yes, that makes sense when *not* in the stateless load
distribution scenario.

[Ballot discuss]
Since the document is giving advice on ECMP, it should alert the reader to the
polarization problem.

The document should also alert the reader to the OAM issues that arise with
ECMP.

[Ballot comment]
Does this document intend to classify RFC 3697 as Historic?

The keyword boilerplate does not include "NOT RECOMMENDED", but the text does (in Section 3).

An informative or perhaps even normative reference to BCP 106 (RFC 4086) might be in order regarding the assignment of flow label values.

An informative reference to RFC 4732 might be in order regarding denial of service.

[Ballot comment]
The Gen-ART Review by Roni Even on 6-Jul-2011 points out one typo in
  section 3, fifth paragraph: "An alternative approach is to to use"

[Ballot comment]
I agree with Wes that the currently stated "MUST NOT change the flow label value"..."A possible exception" formulation in section 2 could be improved editorially. If the questions in my DISCUSS don't lead to a different change, one way to adjust this would be to say something like "MUST either leave the flow label unchanged or change it only as described in section ..."

[Ballot discuss]
It's not clear whether the exceptional token rewriting described in section 6.1 should take the existing flow token into account, or treat the incoming packets as if they had a flow token of zero and behave exactly like a Section 3 forwarding node. If the intent is that this security device is only obfuscating the values some upstream element may have chosen for flow tokens while keeping the flows distinguishable, some additional text should say that and point out what's lost by doing so. If nothing is lost, then why are you keeping the requirement that otherwise forwarding nodes MUST NOT change the flow label value?

[Ballot comment]
The first paragraph of the introduction mentions that a flow could consist of all packets in a specific transport connection.  Many transport connections have bidirectional packet flows.  The authors might consider clarifying whether the same flow label MAY, SHOULD, or SHOULD NOT be used bidirectionally or whether a flow is really just unidirectional.

[Ballot discuss]
In Section 2, paragraph 4, this MUST NOT is clearly a SHOULD NOT as this document itself permits a case where it's allowed to be broken.  MUST NOT is absolute per 2119; no exceptions are allowed.

[Ballot discuss]
This specification uses the full size of the flow label.
Since it has no discriminator to indicate that it is being used for load balancing, no other use can be made of this field.
I would think it might be better to reduce the hash size (maybe to 16 bits) to allow a usage-discriminator so other standardized usages of the flow label could be accomodated.

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:  (IPv6 Flow Label Specification) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'IPv6 Flow Label Specification'
  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-07-13. 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


  This document specifies the IPv6 Flow Label field and the minimum
  requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding
  labeled packets, and flow state establishment methods.  Even when
  mentioned as examples of possible uses of the flow labeling, more
  detailed requirements for specific use cases are out of scope for
  this document.

  The usage of the Flow Label field enables efficient IPv6 flow
  classification based only on IPv6 main header fields in fixed
  positions.




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

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


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

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
I have reviewed this draft.

I think it is in good shape and can move forward once we resolve one issue. Here's the issue:

> A node that forwards a flow whose flow label value in arriving
> packets is zero MAY change the flow label value.  In that case, it is
> RECOMMENDED that the forwarding node sets the flow label field for a
> flow to a uniformly distributed value as just described for source
> nodes.
> o  The same considerations apply as to source hosts setting the flow
>    label; in particular, the normal case is that a flow is defined by
>    the 5-tuple.
> o  This option, if implemented, would presumably be used by first-hop
>    or ingress routers.  It might place a considerable per-packet
>    processing load on them, even if they adopted a stateless method
>    of flow identification and label assignment.  This is why the
>    principal recommendation is that the source host should set the
>    label.
I think this recommendation is problematic. I agree that the first hop router should insert the flow label, but requiring it to do fragment reassembly in order to find the 5-tuple is a big burden, and I'm not sure its even called for.

The RFC 2119 language above is fine. But I'd like to change the part about normal case being the 5-tuple. I think the normal case should be the 2-tuple under these circumstances. The source has access to the 5-tuple; a router is not guaranteed to have access to it.

In addition, I'm not sure I understand how a router knows that it is a first hop router. Are there cases where a device might mistakenly believe it is a first hop router at a point where the traffic has already been load-balanced to multiple routers? Are there situations where the multiple first hop routers are used from the same host? The document should provide some guidance about operational conditions where the recommendations for the first hop router can be applied. The document should state how such functionality is turned on (per configuration? automatically?) and provide assurances that problematic conditions can be avoided.

Document Writeup

draft-ietf-6man-flow-3697bis-04.txt

As required by RFC 4858 , this is the current template
for the Document Shepherd Write-Up.

Changes are expected over time. This version is dated September 17, 2008.

  (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 both members of the 6man WG and the
network operations community. 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.

At this point, the example algorithm provided in Appendix A does not
generate sufficiently distributed flow label values.  Prior to RFC
publication or IETF Last Call, this algorithm will need to be replaced
by the authors.

  (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?

This document has two ID nits warnings which can be fixed during the
next editing phase.  There is a use of a 2119 keyword that is not included
in the 2119 paragraph and there is a reference to a companion document
which has a newer version.

  (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 specifies the IPv6 Flow Label field and the minimum
        requirements for IPv6 nodes labeling flows, IPv6 nodes forwarding
        labeled packets, and flow state establishment methods.  Even when
        mentioned as examples of possible uses of the flow labeling, more
        detailed requirements for specific use cases are out of scope for
        this document.

        The usage of the Flow Label field enables efficient IPv6 flow
        classification based only on IPv6 main header fields in fixed
        positions.

    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.