The flow label, as defined in the draft, eliminates the need of infrastructure devices to snoop at transport (end-to-end) headers. This is a big achievement: after all, the Network should not process anything beyond the network headers.
Host-to-host headers are for processing at source and destination. IPv6 is so generous that it gives us the Destination Options, if we want end-to-end in network layer headers. Final destination hosts will process anyway IPv6 Destination Headers, and transport (host-to-host, or end-to-end) headers. Those headers can carry anything that a source host may mean to send to the final destination, with no touching by forwarding engines. Not to be misunderstood: I am not against end-nodes using the flow label. But that use should mold onto, or piggy-back on a use, or onto a definition that favors or is important to the Network. It would be wrong to do it the other way around, that is to have the flow label use in the Network, piggy-back on host-to-host functions, or definition. So, I think we should be careful and not go too far, with an end-to-end emphasis, that is, restricting the flow label just because of the possible end-node use, to the detriment of possible use in Network (infrastructure) devices. This philosophy guided the original definition of the flow label, reflected in the AH definition, and I agreed then and I agree now with it. Regards, Alex Brian E Carpenter wrote: > > Robert Elz wrote: > ... > > So I'm not sure it is quite true to say that it would never make sense > > for an ISP to do this (including putting the label back on exit) - but > > as long as the label received is the same as the label transmitted, > > there's no way to tell what is going on inside there, nor is there > > any reason for anyone to care. > > I won't argue the point (I think I can prove my assertion that a shim > is the only safe solution, but the margin of this email is too small:). > In practice we agree: the document should say that the flow label > delivered to the destination must be identical to that set at the source. > It's redundant to say any more. > > 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] > --------------------------------------------------------------------
smime.p7s
Description: S/MIME Cryptographic Signature
