Just as a point of clarification, I'm not
categorically against reclassification (though
I'll admit to being wary). What I don't like is
the idea that ESP protection of transport headers
and some diffserv scenarios desire to have them in
the clear are mutually exclusive. Placing some of
those headers into the flow label in a way that
can be analyzed is still subverting the intent
of keeping the transport headers private and
effectively the same as transport friendly ESP
(though, IMO, inferior).
I believe that the way things are being formulated
here is mutually exclusive. The reason is that the
host who ESP-encapsulates the datagram has no clue
without signaling whether it should go the
transport friendly route or the private route.
What that probably means in practice is that
privacy will lose, and that would suck.
Like Francis, I think there is something
fundamentally broken here. I suspect that it is
the base assumption that middle boxen must always
have access to the transport headers. This is a
fundamental shift in the IP architecture, though
I'll admit that it's pretty much as common as dirt
with firewall filtering, NAT's, etc. If we really
want to go here, we should just embrace that
principle and fix the offending protocols. I don't
think I agree with such an architectural change,
but these half-baked attempts at having it both
ways are the worst of both worlds.
Mike
Francis Dupont writes:
> Alex, perhaps I was unfair about the c) option.
> 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, ...
>
> 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.
>
> This point raises a real question about the c) option: what will
> be the content of a flow label with a diffserv semantic? There are
> two kinds of proposals:
> - to pack some bits from protocol/ports into the flow label
> (A.1 or A.2 appendix of your I-D). This will make mapping
> of a 5F classifier to a flow label based one easy but
> the two previous concerns apply. I vote no for this
> interpretation of c).
> - to use an opaque value (a PHB ID as in 7.1.1 of your I-D
> is an obvious candidate) but this doesn't work if a ISP
> doesn't trust you:
> - there is no easy map from a 5F classifier
> - or the PHB is standard and doesn't provide more information
> than the DSCP, or it is not and only some ISPs can interpret it.
> This kind of flow label is an extension of the DS field, it doesn't
> match the requirements for the (broken) MF reclassification and
> is too short for advanced features (for instance a ISP should not
> rewrite it because it is hard to restore it).
>
> I don't vote for or against the second interpretation of c) because
> something is clearly broken somewhere. Tony claims that Diffserv is
> broken and I believe he is right: at least the MF classifier stuff
> has to be more understable... This is a ISP requirement, can ISP people
> explain what they need?
>
> Regards
>
> [EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
