Francis Dupont wrote:
>
> Alex, perhaps I was unfair about the c) option.
You were Francis.
> I understood that you'd like to replace the MF classifier on
> the 5/6 tuple (adresses, DS field, protocol, ports) which I'll call
> the 5F classifier by a simpler MF classifier with the flow label
> in place of protocol and ports. This cancels the efficiency issue
> of the extension header chain of IPv6.
>
> My first concern is the 5F reclassification is a bad idea because
> an ACL-like classifier will never give what I want as an user.
> This is too rigid, not real-time, ...
>
It may not give you what you want as a user, but it would give me
what "I" (read my customers) want as user(s).
Remember, having a Intserv, and Diffserv use of the flow label gives
the user the option, and that is a good thing.
> The second concern is with ESP: the 5F classifier wants to look at
> bits I want to hide. No conciliation is possible, IPsec people
> (like Michael) will *never* accept to reveal transport layer or
> payload details for a 5F classifier. [...]
>
> Francis
Let's put religion aside.
Conceptually, with IP QoS, infrastructure devices delivering packets to
destination, are processing forwarding and QoS information.
As traffic between two end-nodes may have distinct QoS requirements, it
is obvious that the information to be given to an infrastructure device
must provide the differentiation of the traffic between the two
end-nodes.
That information, by definition, is in some relationship with the
multiplexing
of the communication between the two end-nodes, which is being realized
through the
transport (host-to-host) header information. At an extreme, that
information is the
transport protocol and source and destination ports, themselves.
Since, with IP QoS, the QoS information is in the same class, relative
to privacy,
with the forwarding information, if one needs to apply full privacy to
QoS information,
it will apply the same criteria as for forwarding information: use
tunnel ESP.
Regards,
Alex
S/MIME Cryptographic Signature
