I reviewed the revised document today. Speaking as an individual, here
is my reaction:
> Abstract
>
> This document specifies the IPv6 Flow Label field, the requirements
> for IPv6 source nodes labeling flows, and the requirements for flow
> state establishment methods.
Note: what I would expect this draft to describe is:
1) what arbitrary source nodes should do with the flow label.
2) what routers should do with the flow label.
The document appears to do 1), but 2) is omitted from the document. Is
this OK? I.e., I thought the main reason to specify the flow label is
so that current implementations can do something sensible with the
flow label. Is there enough guidance for router implementors (e.g.,
those doing hardware) to add useful support for the flow label? I'm
not sure, but would like to hear from such implementors.
> 2. IPv6 Flow Label Specification
>
> The 20-bit Flow Label field in the IPv6 header [IPv6] SHOULD be used
> by a source to label packets of a flow. A non-zero Flow Label
Note: I don't think the SHOULD/MUST usage in this document is always
helpful or even correct. It would make sense to go read the defintions
in RFC 2119 as cited.
This document defines a flow as the three tuple. No "SHOULD" about
it. If a source wants to label a flow, it does so by setting the flow
label. A better wording would be something like:
Flows in IPv6 identified by the tuple of the 20-bit Flow Label,
the IP source address, and the IP destination address in the IPv6
header.
> The packet MAY be given some flow-specific treatment based on the
> flow state established on a set of IPv6 nodes. The nature of the
MAY here seems odd too. Again, read the definition of MAY. It suggests
that an implementation may decide it makes sense to do something in
certain circumstances. But what I think the document is trying to say
here is that flow-specific processing is done by entities that have
been directed to do so. This is not an implementation choice in the
"MAY" sense. It has more to do whether a device implements flows and
then whether there is appropriate flow-state. Suggested reword:
The packet will be processed in a flow-specific manner by those
nodes that have special processing enabled for packets belonging
to a particular flow.
Actually, the entire paragraph might be better as:
IPv6 flows are defined by the tuple of the 20-bit Flow Label, the
IP source address, and the IP destination address in the IPv6
header. Packet classifiers use the tuple to identify which flow a
particular packet belongs to. Packets will be processed in a
flow-specific manner by those nodes that have special processing
enabled for packets belonging to a particular flow. A Flow Label
of zero indicates an unlabelled packet that is given no special
treatment. The nature of the specific treatment and the methods
for the flow state establishment are beyond the scope of this
specification.
> The Flow Label value set by the source MUST be delivered unchanged to
> the destination node(s).
Question: What is the above intended to mean? That the flow label must
be delivered to the destination unchanged from what it was set to by
the originator? Or that the flow label MUST NOT be modified by any
node along the path? (the two are different, and the words seem to say
the former.) It would be good to be clear.
> IPv6 nodes MUST NOT assume any mathematical or other properties of
> the Flow Label values assigned by source nodes. Router performance
> SHOULD NOT be dependent on the distribution of the Flow Label values.
> Especially, the Flow Label bits alone make poor material for a hash
> key.
I wonder if the above wording is even needed. Can this section just be
dropped? If not, suggested reword:
Some early proposals for use of the IPv6 Flow Label suggested that
routers might use the Flow Label as a hash key for doing lookups as
an optimization. However, this technique assumed that Flow Label
values would make good material for a hash key in order that the
resultant hashes would be sufficiently distributed. In practice,
this cannot be relied upon, and would open up implementations to
potential denial-of-service attacks from attackers that
intentionally violate such an assumption. Consequently, IPv6 nodes
MUST NOT assume any mathematical or other properties of the Flow
Label values assigned by source nodes.
> Nodes keeping dynamic flow state MUST NOT assume packets arriving 60
> seconds or more after the previous packet of a flow still belong to
> the same flow, unless a flow state establishment method in use
> defines a longer flow state lifetime or the flow state has been
> explicitly refreshed within the lifetime duration.
I'm not entirely comfortable with the above wording. It seems to me,
that any node making assumptions about flow values *needs* a flow
setup mechanism to go along with it. But if there is such a mechanism,
that mechanism can communicate appropriate timer values for timing out
state (and the above words are not needed). If there is no such
mechanism, what sort of flow-specific processing should assume that a
gap of 60 seconds implies a reset in the flow?
What problem is the above wording intended to address?
> If an IPv6 node is not providing flow-specific treatment, it MUST
> ignore the field when receiving or forwarding a packet.
Such a node is presumably not implementing this spec, in which case
the words seem superfluous... Delete?
> 3. Flow Labeling Requirements
>
> To enable Flow Label based classification, sources SHOULD assign each
> unrelated transport connection and application data stream to a new
> flow. The source MAY also take part in flow state establishment
> methods that result in assigning certain packets to specific flows. A
> source which does not assign traffic to flows MUST set the Flow Label
> to zero.
I find the above a bit muddled and incomplete. Here is an attempt at
clarifying:
A source enables flow-specific processing by assigning a non-zero
value to the Flow Label on outgoing packets. Because identifying
individual flows may only be possible with the direct help of
individual applications, there is no one rule for how and when to
label outgoing packets. In the absence of more-explicit
information (e.g, from an application), sources SHOULD assign each
new transport connection to a new flow.
Applications should also be provided sufficient control over how
to set the Flow Label. Such indications should support:
- use a specific value for the flow label (e.g., if the
application is participating in a flow setup protocol)
- Let the system pick a value, but provide a way for the
application to specify that a previously-assigned value be
used when sending packets. This is to support applications
that have multiple flows, transported over what the system
might view as a single "connection" or "socket".
... [there are a bunch of things here that it probably makes
sense to at least indicate may be necessary. I don't think
this document should include the API, but it would be good
to itemize the types of operations that will need to be
supported.]
A source that does not desire flow-specific processing sets the
Flow Label value to 0. However, this document requires that
implementations not set the value to 0 by default, in order to
enable the support load spreading.
> A source node MUST keep track of the Flow Label values it is
> currently using or has recently used.
Mumble. the above comes across as a restrictive requirement rather
than focusing on the key requirement to fulfill.
> Flow Label values previously
> used with a specific pair of source and destination addresses MUST
> NOT be assigned to new flows with the same address pair within 60
> seconds of the termination of the previous flow. If the previous flow
> had a lifetime longer than the default 60 seconds, a quarantine
> period of at least the length of the lifetime MUST be observed.
As mentioned above, I'm not sure about the 60 second value. Also, the
wording could be better.
> The requirement of not reusing a Flow Label value for a new flow with
> the same pair of source and destination addresses extends across
> source node crashes and reboots. To avoid accidental Flow Label value
> reuse, the source node SHOULD use a different initial value for Flow
> Label assignments after a reboot. The initial value could be randomly
> generated, or computed from a previous value stored in non-volatile
> memory.
Suggested rewording:
A source node should not reuse a particular Flow Label for a
different flow until it is sure that any flow-specific state on
other nodes has timed out or been appropriately updated. In
particular, if a node reboots, it may lose track of which Flow
Label values it has used recently, and pick the same
ones. Implementations MUST ensure that they don't reuse Flow Labels
too quickly. The problem here is analagous to picking initial
sequence numbers when opening TCP connections after a
restart. There are number of ways to avoid reuse. One approach is
to have new Flow Label values be chosen in some well-defined order
(e.g., sequentially, a pseudo-random sequence, etc.). Upon a system
restart, the initial value could be randomly generated, or computed
from a previous value stored in non-volatile memory.
> 4. Flow State Establishment Requirements
>
> To enable flow-specific treatment, flow state needs to be established
> on all or a subset of the IPv6 nodes on the path from the source to
> the destination(s). The methods for the state establishment, as well
> as the models for flow-specific treatment will be defined in separate
> specifications.
>
> To enable co-existence of different methods in IPv6 nodes, the
> methods MUST meet the following basic requirements:
>
> (1) The method MUST provide the means for flow state clean-up from
> the IPv6 nodes providing the flow-specific treatment. Signaling
> based methods where the source node is involved are free to
> specify flow state lifetimes longer than the default 60 seconds.
>
> (2) Flow state establishment methods MUST be able to recover from
> the case where the requested flow state cannot be supported.
I'm not sure what purpose the above provides. I guess its mostly
harmless, but it strikes me as being pretty obvious, and I wonder if
these are the only real issues to think about. I.e., is this section
complete? If not, do we need it?
> Security Considerations
>
> The use of the Flow Label field enables flow classification also in
> the presence of encryption of IPv6 payloads. This allows the
> transport header values to remain confidential, which may lessen the
> possibilities for some forms of traffic analysis. However, the
> labeling of flows defined in this specification may reveal some
> structure of communications otherwise concealed by transport mode
Seems like more could be said here. If use of the flow label allows
special treatment of traffic, aren't there possible theft of service
issues? Or DOS issues, if someone generates traffic trying to
overwhelm a particular flow? What about authorization? Can anyone set
up flows? Are there requirements or issues here that should be
mentioned in Section 4? This section seems a bit incomplete.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
