> The problem with this is that the text we have today effectively selects
> option b), since it endorses the pseudo-random value. If we do nothing,
> we have effectively chosen the intserv-only usage. That's why I started
> this thread.
Is this really the case?
RFC 2460 actually says:
> 6. Flow Labels
>
> The 20-bit Flow Label field in the IPv6 header may be used by a
> source to label sequences of packets for which it requests special
> handling by the IPv6 routers, such as non-default quality of service
> or "real-time" service. This aspect of IPv6 is, at the time of
> writing, still experimental and subject to change as the requirements
> for flow support in the Internet become clearer. Hosts or routers
> that do not support the functions of the Flow Label field are
> required to set the field to zero when originating a packet, pass the
> field on unchanged when forwarding a packet, and ignore the field
> when receiving a packet.
>
> Appendix A describes the current intended semantics and usage of the
> Flow Label field.
The only place that I know of where the Flow Label bits appear to be
used is in RFC 2205 (Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification). It says:
> 2. IPv6 inserts a variable number of variable-length Internet-
> layer headers before the transport header, increasing the
> difficulty and cost of packet classification for QoS.
>
> Efficient classification of IPv6 data packets could be
> obtained using the Flow Label field of the IPv6 header. The
> details will be provided in the future.
RFC 2205 does include an "IPv6 Flow-label FILTER_SPEC", but by my very
quick skimming this appears to be a separate filter spec in addition
to the normal IPv6 one that just uses ports, address, etc. I.e., its
not required to make use of RSVP in IPv6.
Personally, I do not see the need to further define the Flow Label
field just for the sake of defining it. These are effectively unused
bits that may become useful at some time in the future that we can't
well anticipate. When someone can make a compelling argument for why
the bits need to be defined in a certain way (i.e., there is a real
application for which using the bits provides significant benefits,
and those benefits do not appear achievable through other means) that
is the time to define the bits. What I do sense with many of the
recent discussions surrounding the Flow Label is that there are many
folks (i.e., folks putting IPv6 into hardware) that want to know what
they should implement w.r.t. the Flow Label. While it would be nice to
be able tell them what to do, we shouldn't standardize something just
for the sake of having a definition.
Thomas
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
