Re: Header extension format differences between RFC4326 anddraft-ietf-ipdvb-ule-ext-04.txt

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

No - each H-Type is only specified for the HLEN values described in the 
IANA registry, e.g. in this case 0x0101 would simply be invalid and 
ignored by the receiver (it would skip these bytes without interpreting 
them).

GVorry


Fausto Vieira wrote:
> Hello Gorry,
>
> Many thanks for the explanation.
> I just have one follow up question:
> Is the 257 (0x0101) the Next-header Type that appears in the Type field 
> before the Timestamp extension (probably in the ULE header)?
>
> Couldn't there be a problem if the Next-header Type field (257) and the 
> H-type (1+256) don't match?
>
> Best regards
>
> Fausto
>
>
> Gorry Fairhurst wrote:
> > Hello Fausto,
> >
> > See the answer in-line. Hope this clarifies things for you,
> >
> > best wishes,
> >
> > gorry
> >
> >
> > Fausto Vieira wrote:
> > > Hello all,
> > >
> > > I missed the discussion on the draft-ietf-ipdvb-ule-ext-04.txt so my 
> > > question has probably been raised before:
> > >
> > > Why is it that for the timestamp extension header, the format is:
> > >
> > >    0               7               15              23              31
> > >    +---------------+---------------+---------------+---------------+
> > >    |     0x03      |      0x01     |       time stamp HI           |
> > >    +---------------+---------------+---------------+---------------+
> > >    |         time stamp LO         |            Type               |
> > >    +---------------+---------------+---------------+---------------+
> > >
> > >         Figure 7 The format of the 32-bit Timestamp Extension Header
> > >
> > > where the HLEN (0x03) is at the start of the extension header, when 
> > > in the RFC4326 the extension headers are defined as:
> > The first byte, 0x03, contains the HLEN
> > - i.e in this case, 3 16-bit words, from RFC4326:
> > "3    Indicates an Optional Extension Header of length 6B (Type + 4B)"
> >
> > The IANA has assigned the H-Type of 1 decimal to the timestamp option:
> > http://www.iana.org/assignments/ule-next-headers
> >
> > The entry is:
> >  Type    Name                        H-LEN   Reference
> > ------   --------------------------  -----   ---------
> >   257    Time-Stamp                   3  [RFC-ietf-ipdvb-ule-ext-01.txt]
> >
> > This is a bit cryptic, but entries for Optional Extensions are 
> > recorded as 256+H-Type, or in hex 0x1hh where hh is the H-Type.
> >
> > So, the next field is 0x01. This and the previous byte together forms 
> > the 16-bit value that identifies this Extension Header.
> >
> > >           0                   1
> > >           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
> > >          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >          |0 0 0 0 0|H-LEN|    H-Type     |
> > >          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >
> > >   Figure 7: Structure of ULE Next-Header Field
> > >
> > >
> > > Where it is stated that the H-Type is 8-bit and not 16-bit. To my 
> > > knowledge, Ethertype should always be 16-bit.
> > RFC4326 states:
> > "The H-Type is a one-byte field that is either one of 256 Mandatory
> >    Header Extensions or one of 256 Optional Header Extensions."
> > - so this forms the second byte of an extension header.
> >
> > > However, my question is:
> > > What is the meaning of the 0x01 byte in the Timestamp Header?
> > > Is this the  1 microsecond resolution value or is this some type of byte
> > > alignment?
> > See above.
> > > Many thanks
> > >
> > > Fausto Vieira