El 27/06/2006, a las 11:05, Iljitsch van Beijnum escribió:
On 22-jun-2006, at 17:14, marcelo bagnulo braun wrote:first of all, the possibility of using the flow label is not considered, why is that?I know that we had long discussions about this but I can't seem to remember what's useful about using the flowlabel...
well, the benefit is that you don't have the overhead of the extension header and you don't rely on specific ulp
the drawbacks are that you need the shim bit int he v6 header (i.e. new next header values for common protocols and that you are imposing (a few) constraints on future usages of the flow label field for shimmed packets)
we have included a summary of the discussion in Appendix D.2 of the shim protocol draft which i think describes pretty much how a solution based on the flow label could be done. i guess this could be a starting point
I think it is a good option and it is much cleaner than using the tcp/UDP ports... i would suggest to include it.I'll dredge up ealier discussions.Second, i am not sure if using transport ports is the best option since it would limit the context to a single communication... or are you considering binding multiple port pairs to the same shim context?... in any case, i guess we would need to flesh out this a bit more in order to understand how would it work...I agree that this isn't necessarily the best way to do it, but if a receiver says it can demultiplex on port numbers, why not take advantage of that?
because of complexity... special cases introduce additional complexity, since you need to deal with TCP, UDP, IPSec, and so on
I would rather have a solution that are general, like the flow label one.
besides, as i pointed earlier you would need to associated a context to each transport connection, right?
I'll look at the multiple sessions per context issue.Another possibility would be to use IPSec SPI field, a la hip, in case that the communication is using IPSecYes, this could be useful.When bit 0 is set, the host indicates that it knows how to demultiplexpackets belonging to the shim context being negotiated under all circumstances, so the sender MUST NOT add a shim header to these packets.However, in most cases (as outlined earlier) the cooperation of the sender is required to make sure that multiplexing can be donesuccessfully, so when bit 0 is set to zero, the shim6 header may only besuppressed when the hosts involved have at least one capability incommon. If there is any doubt, the shim6 header MUST NOT be suppressed.i fail to understand this part...i mean when bit 0 is set, the peer must or must not suppress the header?Each bit indicates a capability that may or may not apply in a given situation. For instance, if the bit for transport demultiplexing is set, but there is a session from A1 to B1 and from A2 to B1 where both sessions use the same port number, it won't be possible to demultiplex on transport information alone. So in order to be able to suppress the header, the sender and receiver must have set the same bit, and the sender must know that the state between the hosts conforms to the limitations of the demultiplexing strategy that is indicated by the bit in question. Only if that's the case, the sender may suppress the header.Bit 0 is a special case, because there are no limitations: if this bit is set, the header MUST always be suppressed.
yes i think i understand that, but then it is stated that in case of doubt the shim6 header must not be suppressed (even if bit 0 is set) This is what i find confusing.... I guess that what it should be stated is that if the peers are not sure they can suppress the header, the must not set bit 0
Regards, marcelo
Iljitsch