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.
Quite agree. This option doesn't work. Sorry if the draft doesn't make it
clear that we reject it.
>
> 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.
This is debatable. Since there is a potentially large number of IANA-registered
PHB IDs, they can actually be given more semantics than a true PHB. It's
certainly stretching the concept. It's also the only way I can see to make the
flow label relevant to diffserv; but we are at liberty to conclude that it
can't be done and we leave the flow label exactly as it is, relevant only
to intserv.
> 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.
Well yes, but when the packet has an ESP header you are in trouble. The idea
of adding some semantics in the flow label is to deal with the ESP case.
If you aren't prepared to believe that field then of course all is lost
and you can only do address based classification.
Regards
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
