Discussion.

Requirements of RFC2460 are pretty tough. Particularly, lifetimes longer than boot time require to store allocated labels at stable storage, so that the full implementation necessarily includes user space flow label manager. There are at least three different approaches:

1. ``Cooperative''. We could leave flow label allocation wholly to user space. When user needs label he requests manager directly. The approach is valid, but as any ``cooperative'' approach it suffers of security problems.

   1cm NB. One idea is to disallow not privileged user to allocate flow labels, but instead to pass the socket to manager via SCM_RIGHTS control message, so that it will allocate label and assign it to socket itself. Hmm... the idea is interesting.

2. ``Indirect''. Kernel redirects requests to user level daemon and does not install label until the daemon acknowledged the request. The approach is the most promising, it is especially pleasant to recognize parallel with IPsec API [RFC2367,Craig]. Actually, it may share API with IPsec.

3. ``Stupid''. To allocate labels in kernel space. It is the simplest method, but it suffers of two serious flaws: the first, we cannot lease labels with lifetimes longer than boot time, the second, it is sensitive to DoS attacks. Kernel have to remember all the obsolete labels until their expiration and malicious user may fastly eat all the flow label space.

Certainly, I choose the most ``stupid'' method. It is the cheapest one for implementor (i.e. me), and taking into account that flow labels still have no serious applications it is not useful to work on more advanced API, especially, taking into account that eventually we will get it for no fee together with IPsec.