RFC 1809 (rfc1809) - Page 3 of 6
Using the Flow Label Field in IPv6
Alternative Format: Original Text Document
RFC 1809 June 1995
In any case, it is clear that treating this situation as an error
and, say dropping the datagram and sending an ICMP message, is
inappropriate. Indeed, it seems likely that in most cases, simply
forwarding the datagram as one would a datagram with a zero Flow
Label would give better service to the flow than dropping the
datagram.
Of course, there will be situations in which routing the datagram as
if its Flow Label were zero will cause the wrong result. An example
is a router which has two paths to the datagram's destination, one
via a high-bandwidth satellite link and the other via a low-bandwidth
terrestrial link. A high bandwidth flow obviously should be routed
via the high-bandwidth link, but if the router loses the flow state,
the router may route the traffic via the low-bandwidth link, with the
potential for the flow's traffic to swamp the low-bandwidth link. It
seems likely, however, these situations will be exceptions rather
than the rule. So it seems reasonable to handle these situations
using options that indicate that if the flow state is absent, the
datagram needs special handling. (The options may be Hop-by-Hop or
only handled at some routers, depending on the flow's needs).
It would clearly be desirable to have some method for signalling to
end systems that the flow state has been lost and needs to be
refreshed. One possibility is to add a state-lost bit to the Flow
Label field, however there is sensitivity to eating into the precious
24-bits of the field. Other possibilities include adding options to
the datagram to indicate its Flow Label was unknown or sending an
ICMP message back to the flow source.
In summary, the view is that the default rule should be that if a
router receives a datagram with an unknown Flow Label, it treats the
datagram as if the Flow Label is zero. As part of forwarding, the
router will examine any hop-by-hop options and learn if the the
datagram requires special handling. The options could include simply
the information that the datagram is to be dropped if the Flow Label
is unknown or could contain the flow state the router should have.
There is clearly room here for experimentation with option design.
Flushing Old Flow Labels
The flow mechanism assumes that state associated with a given Flow
Label is somehow deposited in routers, so they know how to handle
datagrams that carry the Flow Label. A serious problem is how to
flush Flow Labels that are no longer being used (stale Flow Labels)
from the routers.
Stale Flow Labels can happen a number of ways, even if we assume that
the source always sends a message deleting a Flow Label when the
Partridge Informational