Subject: [IPFIX] RFC 5102 errata 1737, 1738 and 1739

From: Paul Aitken <[email-masked]>
Date: Tue, 09 Aug 2011 12:40:39 +0100

Dear IPFIXers,

I've been reviewing RFC5102 errata 1737, 1738 and 1739 which tried to 
correct the bit-numbering of the "ipv4Options", "ipv6ExtensionHeaders" 
and "tcpOptions" information elements.

See:
     http://www.rfc-editor.org/errata_search.php?eid=1737
     http://www.rfc-editor.org/errata_search.php?eid=1738
     http://www.rfc-editor.org/errata_search.php?eid=1739

While these errata corrected the bit ordering within the bytes, they 
left the wrong byte ordering - which leaves things worse than before.

I hope that anyone who has implemented ipv4Options, 
ipv6ExtensionHeaders, or tcpOptions, has followed the text rather than 
the figures?

eg, consider errata 1737 for ipv4Options.

The options are defined in RFC 791 and assigned by IANA:
     http://www.iana.org/assignments/ip-parameters

Each option has a number, from 0 to 30. The intention was for the 
ipv4Options bits to follow that numbering, with bit = 2^number.

Unfortunately RFC bit numbering is from left to right, so we originally 
followed that and drew the figure like so:

            0      1      2      3      4      5      6      7
        +------+------+------+------+------+------+------+------+
        | EOOL | NOP  | SEC  | LSR  |  TS  |E-SEC |CIPSO |  RR  | ...
        +------+------+------+------+------+------+------+------+

That's exactly the reverse of what we had intended, which was like this:

        +------+------+------+------+------+------+------+------+
    ... |  RR  |CIPSO |E-SEC |  TS  | LSR  |  SEC | NOP  | EOOL |
        +------+------+------+------+------+------+------+------+

Errata 1737 fixed the bit ordering within the bytes, but left the wrong 
byte ordering.
And that's what's currently shown in IANA's IPFIX registry, 
http://www.iana.org/assignments/ipfix/ipfix.xml :

            0      1      2      3      4      5      6      7
        +------+------+------+------+------+------+------+------+
        |  RR  |CIPSO |E-SEC |  TS  | LSR  | SEC  | NOP  | EOOL | ...
        +------+------+------+------+------+------+------+------+

            8      9     10     11     12     13     14     15
        +------+------+------+------+------+------+------+------+
    ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU  | SSR  | SID  | ...
        +------+------+------+------+------+------+------+------+

           16     17     18     19     20     21     22     23
        +------+------+------+------+------+------+------+------+
    ... | DPS  |NSAPA | SDB  |RTRALT|ADDEXT|  TR  | EIP  |IMITD | ...
        +------+------+------+------+------+------+------+------+

           24     25     26     27     28     29     30     31
        +------+------+------+------+------+------+------+------+
    ... |      |  EXP |   to be assigned by IANA  |  QS  | UMP  |
        +------+------+------+------+------+------+------+------+

If you think of this as a 32-bit word, EOOL is at position 2^24, which 
you couldn't possibly infer from the associated text.

The correct ordering is:

            0      1      2      3      4      5      6      7
        +------+------+------+------+------+------+------+------+
        |      |  EXP |   to be assigned by IANA  |  QS  | UMP  | ...
        +------+------+------+------+------+------+------+------+

            8      9     10     11     12     13     14     15
        +------+------+------+------+------+------+------+------+
    ... | DPS  |NSAPA | SDB  |RTRALT|ADDEXT|  TR  | EIP  |IMITD | ...
        +------+------+------+------+------+------+------+------+

           16     17     18     19     20     21     22     23
        +------+------+------+------+------+------+------+------+
    ... |ENCODE| VISA | FINN | MTUR | MTUP | ZSU  | SSR  | SID  | ...
        +------+------+------+------+------+------+------+------+

           24     25     26     27     28     29     30     31
        +------+------+------+------+------+------+------+------+
    ... |  RR  |CIPSO |E-SEC |  TS  | LSR  | SEC  | NOP  | EOOL |
        +------+------+------+------+------+------+------+------+

If you ignore the bits-on-the-wire numbering and imagine this as a 
32-bit word in memory, each option is at (2^value) as you'd expect.

Unfortunately the RFC numbering is exactly the reverse of the values in 
the "ip-parameters" registry - which is what led to all this confusion. 
However there's no reason or need for these to agree.

The exact same issues exist with errata 1738 and 1739: the bit ordering 
was swapped, but not the byte ordering.

I'm opening new errata to correct all this properly.

P.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 11 Aug 2011 12:24:59 +0200

Hi,

Would it be possible that you propose the errata (as a plural) on the WG
list, and the WG discussed them before? 

The submission many errata (the last batch included more than 20) in one
day is quite a load on the AD who needs to verify and approve them. I
prefer the exact text to be submitted and discussed on the ipfix WG list
BEFORE submitting. Of course, this is just a suggestion. 

Thanks and Regards,

Dan 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Aitken
> Sent: Tuesday, August 09, 2011 2:41 PM
> To: IETF IPFIX Working Group
> Subject: [IPFIX] RFC 5102 errata 1737, 1738 and 1739
> 
> Dear IPFIXers,
> 
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Thu, 11 Aug 2011 13:07:39 +0100

Dan,

> list, and the WG discussed them before?

Sure, will do.

> BEFORE submitting. Of course, this is just a suggestion.

I didn't plan to submit the batch; I just started reviewing the 
documents (especially considering the proposed update to the IPFIX base 
standards) and one thing led to another.
Most of the points were minor editorial issues and inconsistencies.

However, errata 1737, 1738 and 1739 are technical issues.

P.