[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim header in every shimmed packet

On 12-okt-2005, at 12:09, Erik Nordmark wrote:
And of course, it doesn't get any simpler than simply putting in an explicit shim6 header with the context tag in every shimmed packet. This is what's on the table now. 


Iljitsch,
it is not in every packet.
It is only in packets after a locator switch i.e., when the IPv6 source and/or destination are different then the ULIDs. 

That's what I meant with "every shimmed packet".
Looks like you are assuming that there will be failures all the time so that NO packet will have ULIDs=locators. 

Of course not. Most packets will not be rewritten by the shim.
However, when this capability becomes common it's not inconceivable that people are going to let it catch stuff that is now repaired differently, so that rewriting becomes more common that it would seem extrapolating the current situation.
And of course there is traffic engineering, which may lead to a fairly large amount of rewriting.
Isn't the receiver's ability to demux the packets to the correct context without the context tag a function of the locator sets and ULIDs that are in use? 
If so I don't see how a single bit can suffice.
It seems like one would need to at a minimum covey that bit in the Update Ack message (in addition to the context establishment) so that when the peer changes its locators, the host can restate whether or not it can demux without the context tag for the new set of locators.
Right. I haven't thought much about the issues around locator updating because I was kind of assuming this wouldn't happen in the presense of HBA.
But the current design also uses uncoordinated teardown of the context state, which can result in one end not having any context state any more, even though the peer might send packets using that context. With the context tag in the packets that need to be rewritten by the receiver, we can detect this condition. But your 'single bit' scheme would seem to need some different way to detect this missing state. Any ideas on how to do this?
That would be something that we explore in the "how to safely suppress the shim header after rewriting" document but in the case where the locator sets for the different ULIDs are disjoint this isn't an issue: the receiver without state that receives a shimmed packet without a shim header will know this because the packet is addressed at a locator-only address. It can then either send back a shim error or an ICMP error.