Re: Flow label versus Extension header - protocol itself

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Marcelo,

marcelo bagnulo braun wrote:
[cut]
> > Yes, this is the case.  If the existing 3697 (sender side) allocation
> > for flow labels is used, then explicit signaling to add each
> > <source,dest,label> to a multihoming context has to precede packet
> > delivery.
>
> Maybe i am missing something here, but this is the case, independently 
> of the mechanisms you choose to carry the context tag, because of 
> security issues....
>
> I mean when a node is adding a new locator into an established shim 
> context, it must send an explicity message, informing of that new 
> locator and including security information in order to validate this new 
> locator. In this exchange used to add and verify the new locator, the 
> receiver could inform the transmitter about the new flow label value (if 
> needed)
>
> So i would say that explicit signaling when adding a new locator is 
> always needed.

Yes, it's always needed, but the time ordering of the packets to do
the signalling may not be strict.

If the upper layer protocol is ESP with authentication (or AH), for
example, it will be possible to identify that the flow belongs to an
upper-layer data stream because of the SPI, and the fact that the
packet authenticates using the right HMAC.

This may not be palatable to all, but the possibility is there
(and may be dismissed later).

Packets sent before the signaling wouldn't be guaranteed to get
through, but if the actual signaling took computation time
(or a longer, reliable signaling path), this is an optimization
which would work well for some data.

Please note that if strict ordering of signaling before packet
arrival is required, then receiver side flow label allocation
isn't required itself for ensuring decodability just based on
the IPv6 header.  Only unique-to-sender label allocation is
needed to avoid label collision, since no label selected on the
host will collide with its own (going to any of its destinations),
and the <source, label> pair is sufficient to identify it
to the receiver.

> a possible question would be if it would be possible to include the 
> signalling in the same packet that carry the new locator as source 
> address... i guess this depends on how you define the packet processing, 
> but i guess it may be possible in any case.

I'm not really fond of piggybacking data.

It's possible of course but has potential issues with MTU.

Separate signaling is also much easier to describe and
implement.

Greg