On 6/6/13 10:41 PM, Ray Hunter wrote:
joel jaeggli <mailto:[email protected]>
6 June 2013 22:19
On 6/6/13 4:09 PM, Fernando Gont wrote:
On 06/06/2013 06:20 PM, Nalini Elkins wrote:
So, if we are talking about the MTU of the local egress interface, then
since, I believe, the minimum MTU size for IPv6 is 1,280, then all
devices should be prepared to examine up to 1,280 bytes to get the L4
header?
In theory, yes. In practice, it wouldn't make much sense, probably (most
of the packet containing overhead?).
There's a question you can pose to an asic designer... What does it
cost at this point to extend the header processing from 53/64/128/256
bytes. bearing in mind also that part of the reason that the space
already has increased is due to encapsulation, label-in-label q-in-q
so the ipv6 header is not the only thing competing for more room.
Cheers,
May I suggest some other questions:
Does size matter?
It does because typically the memory associated with the
forwarding/header lookup is very fast and expensive. It never holds the
whole packet currently. This was of course in our draft.
Or is the complexity of the ASIC implementation of a header chain parser
more heavily influenced by the fact that the header chain is defined as
a linked list of type-length-value items that can be built up in any
number of valid combinations, and so has to be traversed and interpreted
at every individual link?
Traversal is expensive yes.
What if the most common individual TLV option tokens were standardized
further?
And the transmission order fixed?
What if the most common individual extension headers were standardized
further?
And the transmission order fixed?
Would this help make hardware parsing possible/economic?
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
