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.
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, and furthermore,
the downstream network usually couldn't care less what the application
desires.
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). When crossing security
boundaries the only field which I am reasonably safe to trust is the
destination address. Protocol/port filtering only makes sense within
an enterprise network or at the access provider's edge.
Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake <[EMAIL PROTECTED]>
Ericsson IP Infrastructure (919)472-9913
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
