Lines Matching refs:to
23 these bits to two fields: 8 bits of traffic class (or DS field, if you
25 no well-defined API to manage IPv6 flow information. In this document
26 I describe an attempt to design the API for Linux-2.2 IPv6 stack.
34 \item To allow user to set traffic class bits.
36 \item To allow user to read traffic class bits of received packets.
38 necessary f.e.\ to implement ECN [RFC2481] for datagram oriented services
39 or to implement receiver side of SRP or another end-to-end protocol
42 \item To assign flow labels to packets sent by user.
46 want to use flow labels to distinguish sub-flows.
48 \item To allocate flow labels in the way, compliant to RFC2460. Namely:
58 hop by hop options and all the headers up to and including routing header,
74 Flow labels have finite lifetime and source is not allowed to reuse
76 so that intermediate nodes will be able to invalidate flow state before
92 to solve the first four tasks using
93 \verb|sin6_flowinfo| field added to \verb|struct| \verb|sockaddr_in6|
97 This method is difficult to consider as reasonable, because it
98 puts additional overhead to all the services, despite of only
99 very small subset of them (none, to be more exact) really use it.
100 It contradicts both to IETF spirit and the letter. Before RFC2553
106 if \verb|recvmsg()| initializes \verb|sin6_flowinfo| to flow info
108 namely, we are not allowed to use received address for reply directly
109 and have to mangle it, even if we are not interested in flowinfo subtleties.
112 RFC2553 adds new requirement: to clear \verb|sin6_flowinfo|.
113 Certainly, it is not solution but rather attempt to force applications
114 to make unnecessary work. Well, as usually, one mistake in design
115 is followed by attempts to patch the hole and more mistakes...
136 assuming that common applications are not obliged to initialize it
137 and are permitted to consider it as pure alignment padding.
138 In order to tell kernel that application
139 is aware of this field, it is necessary to set socket option
149 message to user space, though the kernels which support flow labels
150 initialize it to zero. If user wants to get received flowinfo, he
165 may be used as alternative way to send flowinfo with \verb|sendmsg()| or
166 to latch it with \verb|IPV6_PKTOPTIONS|.
181 In the cases when it is convenient to use \verb|recvfrom(2)|,
182 it is possible to replace library variant with your own one,
223 longer than boot time require to store allocated labels at stable
229 to user space. When user needs label he requests manager directly. The approach
233 One idea is to disallow not privileged user to allocate flow
234 labels, but instead to pass the socket to manager via \verb|SCM_RIGHTS|
235 control message, so that it will allocate label and assign it to socket
239 \item {\bf ``Indirect''.} Kernel redirects requests to user level daemon
241 The approach is the most promising, it is especially pleasant to recognize
248 it is sensitive to DoS attacks. Kernel have to remember all the obsolete
256 still have no serious applications it is not useful to work on more
263 Socket option \verb|IPV6_FLOWLABEL_MGR| allows to
264 request flow label manager to allocate new flow label, to reuse
265 already allocated one or to delete old flow label.
289 to lease flow label ordered by user. In this case, it is user task to provide
305 #define IPV6_FL_F_CREATE 1 /* Allowed to create new label */
310 \item \verb|share| defines who is allowed to reuse the same flow label.
324 unprivileged user to set linger longer than 60 sec.
329 unprivileged user to set timeout longer than 60 sec. Proviledged applications
410 without any modifications to standard ISI RAPI. Sender must allocate
411 flow label, fill corresponding sender template and submit it to local rsvp
412 daemon. rsvpd will check the label and start to announce it in PATH
417 \verb|rtap| utility is modified to parse flow labels. F.e.\ if user allocated