[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Filter Separation using a NULL?
To clarify Mauricio's question, I've changed the text somewhat. The updated
text is available for inspection here:
Here is how the new Section 2 reads:
2. NAS-Filter-Rule Attribute
This attribute indicates filter rules to be applied for this user.
Zero or more NAS-Filter-Rule attributes MAY be sent in Access-
Accept, CoA-Request, or Accounting-Request packets.
The NAS-Filter-Rule attribute is not intended to be used
concurrently with any other filter rule attribute, including
Filter-Id (11) and NAS-Traffic-Rule [Traffic] attributes, and MUST
NOT appear in the same RADIUS packet. If a Filter-Id or NAS-
Traffic-Rule attribute is present, then implementations of this
specification MUST silently discard NAS-Filter-Rule attributes, if
Where multiple NAS-Filter-Rule attributes are included in a RADIUS
packet, the String field of the attributes are to be concatenated
to form a set of filter rules. As noted in [RFC2865] Section 2.3,
"the forwarding server MUST NOT change the order of any attributes
of the same type", so that RADIUS proxies will not reorder NAS-
A summary of the NAS-Filter-Rule Attribute format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type | Length | String...
The String field is one or more octets. It contains filter rules
in the IPFilterRule syntax defined in [RFC3588] Section 4.3, with
filter rules separated by a NULL (0x00). One or more filter rules
may be included within a NAS-Filter-Rule attribute, and filter
rules may be continued across attribute boundaries, so in general
implementations cannot assume that filter rules begin and end on
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.