Tony,
I may be repeating myself, but exactly because the *ports* are immutable,
they are *useless* for intra-operator diffserv MF-classification. Having a
non-locally-mappable but mutable field with standardized semantics AND
SLA-based strict tie-in to policing/charging/remarking is what is needed for
diffserv intra-operator BA classification.
Now, DSCP would be all that is needed, if it weren't irreversibly mappable.
Now it seems that we need to give one bit away from the flow label to fix
this. If this will result in network middleboxes snooping less on the
host-to-host transport headers, I'm happy :-)
The host-to-host flow labels will need to remain immutable.
Jarno
PS: Aren't the "well known ports" defined just to facilitate end-to-end
rendezvous? Quite a leap to base any policy decisions on ports...
Tony Hain wrote:
> Brian Carpenter wrote:
>
> > This is a very unfair comment. Diffserv is just fine in the
> > case of unencrypted traffic. It has a problem (and so does
> > intserv I suspect) with tunnel or transport mode ESP.
>
> But that is the point. If IPsec had been widely deployed in the
> IPv4 Internet, diffserv would have been forced to fix the DSCP
> end-to-end, because that would be the only alternative.
>
> > No it doesn't. They should be set at source. (But anyway, why
> > would it matter if they are mutable, since they aren't covered
> > by checksum? I'm not aware of a law of nature against mutable bits.)
>
> Speak to your co-author who keeps insisting that they are
> mutable. In any case, the point is that for diffserv to work there
> has to be a visible set of bits that are immutable end-to-end
> with well-known semantics. Currently that is the protocol/port,
> simply because ESP wasn't in widespread use. In IPv6 we assume
> it will be, so diffserv needs another set of bits that have an
> immutable well-known end-to-end semantic.
>
> > No, that is in fact what we did, but at the specific insistence
> > of the ISPs active in the design of diffserv, we made all of
> > the mappings SHOULD instead of MUST. You want to ding the WG
> > for meeting a clearly stated key requirement of the principal
> > customer set?
>
> In this case yes, because that requirement results in an
> inoperable state when security is applied. RFC 2475 starts the
> discussion about IPsec interactions, but only from the perspective
> of protecting the DSCP. It misses the point that when ESP is in
> use there is no visible set of bits to base decisions on for
> each domain to set the DSCP. The only set of bits there is left
> to work with is the SPI, and the semantics of that are only
> known between the endpoints unless signalled via RSVP.
>
> > Products work just fine the way things are.
>
> In fact that is a false statement because those products can't
> work today if one tries to use an encrypted channel.
>
> > Immutablity isn't the problem. Encryption of the port and protocol
> > numbers is the problem. I could equally well say that IPSEC should
> > go back and fix the invisibility problem they created.
>
> That is a specific feature. There are many times when you don't
> want traffic analysis done on the ports in use and number or sequence
> of packets between them.
>
> > What I am actually
> > saying is that this WG should go back and fix the ambiguity problem
> > created by the Appendix to RFC 2460.
>
> No argument, but the only ambiguity I see is the comment about
> control protocols. The rest of the text is very clear.
>
> Tony
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
