On 24-apr-2005, at 19:52, Erik Nordmark wrote:
Yes, but not necessarily at this point. Presumably, the shim
address remapping will happen early in the processing of a packet,
while scanning the full list of extension headers happens much later.
Can you explain why such (undesired from a performance perspective)
type of behavior would be required?
Well, I can't be sure, but if processing of any other headers that may
be present requires knowledge of the ULIDs then it could be necessary
to go through the list of headers twice.
But...
AFAIK it is sufficient for the implementation to step through the
extension headers, and when and if it finds a shim6 extension header,
it would lookup the shim6 context state, and remap the IP address
fields to the ULIDs that are contained in that context.
I guess that that should be enough if we can proscribe that the headers
that come before the shim header (counting from the beginning of the
packet, not the order in which they are created) only deal with the
locators and the ones that come later only deal with the ULID.
So in that case there aren't any adverse effects when the header isn't
present.
I still don't like it, though. :-)
(And the argument that a header will give us a more bits is a fallacy,
20 bits is already more than we should want to use up. Less is more, as
a long label only increases lookup times.)