Steve,
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > The traffic class field is not enough. If you have to re-classify traffic at
> > an administrative boundary, then by definition at that point the traffic class
> > field is inadequate; you need more information. The advantage that IPv6 has
> > is that even when the header is partly hidden by IPSEC, the flow label is
> > available to carry additional semantics. The actual proposal is to use the
> > PHB identifier which has end to end semantics.
>
> Brian,
>
> The counter argument against putting port information in the flow label
> is that it gives the application the incentive to lie (by putting bogus
> information in the flow label), without the impact of breaking the receiver's
> port demultiplexing.
>
Independent of what Brian may have to say....
What you say gives the impression that the draft introduces a higher
security risk, but that is
absolutely not true.
The QoS processing is affected the same way, whether there is a port
number or something else in the flow label. That is to say that the
security impact of using a port number, or any other label format, is
not different than with the RFC 2460 definition of the flow label
format, if a user can
change as pleases packet headers before packets are sent.
> The counter argument against putting the PHB id in the flow label is that
> it is irrelevant: the way PHBs have been defined has virtually no
> relationship to any application QoS performance parameters,
The relationship or non-relationship with an application prior to using
the PHB value in the flow label is irrelevant. One could use anything as
a value, including a predefined IANA value. Using the PHB ID is clever,
because it avoids the hassles of another set of IANA numbers.
> and furthermore,
> the downstream network usually couldn't care less what the application
> desires.
>
It is correct to say "usually", because it is not "always". There are
plenty of situations, where there is a merit for the downstream
providers. Nevertheless, it was stated quite clearly in the draft, the
best and direct application is in access networks.
> If I am reclassifying traffic at an administrative boundary then by
> definition I don't care about or trust the "QoS information" in the
> packet as anything more than a hint which I am free to ignore (depending
> on the TCS I have with the upstream network).
You are free to ignore, but you should also be free to consider,
depending on SLS/TCS. The point is in giving the users/providers the
choice.
> [...]
> Steven L. Blake <[EMAIL PROTECTED]>
> Ericsson IP Infrastructure (919)472-9913
Alex
S/MIME Cryptographic Signature
