First of all: IMHO the final call for this I-D should be as fast as possible.
We currently employ equipment _without_ this extension header (of course ;)
_and_ the equipment cannot be extended because it is certified, sorry for real
life issues ;). Furthermore, if I remember correctly there where no objections
in Beijing against this I-D.
Anyway, one suggestion:
Why not extend the header and use a slightly other format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Specific Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Header Specific Data .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Why this avoidable overhead?
1. For 99% of the extension header this is no overhead! The padding will
lift the overall size:
i: Intrinsic Extension Header Size
j: Intrinsic Extension Header + GIEH Header
k: Intrinsic Extension Header + new GIEH Header
i | j | k
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 Byte | 4 Byte | 8 Byte
2 Byte | 8 Byte | 8 Byte <--
3 Byte | 8 Byte | 8 Byte
4 Byte | 8 Byte | 8 Byte <--
5 Byte | 8 Byte | 12 Byte
6 Byte | 12 Byte | 12 Byte
8 Byte | 12 Byte | 12 Byte <--
... | ... | ...
In praxis there will be nearly no overhead because I do not except one byte
extension header. For other Extension Header Sizes (I expect even sized
extension header) the reserved Byte does not matter.
2. The Reserved Byte make GIEH backward compatible ("the reserved byte MUST be
ignored") if the proposed 2 Bit signaling is required, sometime. Maybe some
other signaling is also required.
3. The processing overhead and complexity to shift fields is not to underrate.
I mean it is complete awkward to put a u32 not on natural boundary.
Cheers, Hagen
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
