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.