Subject: [IPFIX] RFC5102 errata

From: Paul Aitken <[email-masked]>
Date: Tue, 24 Mar 2009 16:50:00 +0000

Dear Chairs,

While this issue was briefly discussed yesterday, I believe Benoit was 
caught unexpectedly and wasn't prepared to discuss the issue fully. And 
being remote on jabber, it was difficult for me to jump in with a brief 
summary at the time.

However, I believe the conclusion reached in the WG yesterday (ie, to 
deprecate the IEs and create new ones) is not the correct solution.

 From my perspective,

1. Several IEs are incorrectly described, not just isMulticast.
    Specifically: isMulticast, ipv4Options, ipv6ExtensionHeaders,
    tcpOptions.

2. The main issue is that the RFC 5102 diagrams conflict with the text.

3. There are backwards compatibility issues with NFv9.

Note that I first announced these issues eight months ago:

   http://www.ietf.org/mail-archive/web/ipfix/current/msg04383.html

I've just submitted four errata to allow the issues to be tracked.

Before the details, let's first ensure that we agree the bit ordering in 
RFCs.

Per appendix B of RFC 791:

   Whenever an octet represents a numeric quantity the left most bit
   in the diagram is the high order or most significant bit.  That is,
   the bit labeled 0 is the most significant bit.

And again:

   Similarly, whenever a multi-octet field represents a numeric quantity
   the left most bit of the whole field is the most significant bit.
   When a multi-octet quantity is transmitted the most significant octet
   is transmitted first.

So, with that in mind, I examined the following fields:

* isMulticast

     For backwards compatibility with NFv9, the "MCv4" bit should have
     the values 0 and 1 - ie, it should be in the LSB position.

     Since RFC 791 specifies that "the bit labeled 0 is the most
     significant bit", the diagram depicting the bits is reversed.
     It should be:

             0      1      2      3      4      5      6      7
          +------+------+------+------+------+------+------+------+
          |   IPv6 multicast scope    |  T   | RES. | RES. | MCv4 |
          +------+------+------+------+------+------+------+------+

     Unfortunately the T bit now ends up offset by one from its position
     in RFC 4291. Too bad.

* fragmentFlags

     The RS, DF and MF flags come directly from RFC 791,
     where they're in the same format and position.
     So this is fine.

* mplsTopLabelExp, postMplsTopLabelExp

     No problem, except that this is offset by one bit (the "S" bit)
     from the position shown in RFC 3032.

* mplsTopLabelStackSection

     Exactly as shown in RFC 3032, so no issue.

* ipv4Options

     While all the text is good, since RFC 791 specifies that "the bit
     labeled 0 is the most significant bit", the diagram depicting the
     bits is reversed. It should be:

            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  |
        +------+------+------+------+------+------+------+------+

     Because RFC 791 defines:

	EOOL = 0
	NOP  = 1
	SEC  = 2
	LSR  = 3
	...

* ipv6ExtensionHeaders

     RFC 5102 says:

       For each IPv6
       option header, there is a bit in this set.  The bit is set to 1 if
       any observed packet of this Flow contains the corresponding IPv6
       extension header.

     While all the text is good, since RFC 791 specifies that "the bit
     labeled 0 is the most significant bit", the diagram depicting the
     bits is reversed. It should be:

              0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | DST | HOP | Res | UNK | FRA0| RH  | FRA1| Res |  ...
           +-----+-----+-----+-----+-----+-----+-----+-----+

               8     9    10    11    12    13    14    15
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |         Reserved            | ESP | AH  | PAY |...
           +-----+-----+-----+-----+-----+-----+-----+-----+

     So, eg, when a HBH head (value 6) is seen, bit 2^6 will be set,
     ie ipv6ExtensionHeaders = 32.

     Now, comparing RFC 5102, IANA and IOS:

	RFC 5102 specifies:

        Bit    IPv6 Option   Description

        0, Res               Reserved
        1, FRA1     44       Fragmentation header - not first fragment
        2, RH       43       Routing header
        3, FRA0     44       Fragment header - first fragment
        4, UNK               Unknown Layer 4 header
                             (compressed, encrypted, not supported)
        5, Res               Reserved
        6, HOP       0       Hop-by-hop option header
        7, DST      60       Destination option header
        8, PAY     108       Payload compression header
        9, AH       51       Authentication Header
       10, ESP      50       Encrypted security payload
       11 to 31              Reserved

     Whereas http://www.iana.org/assignments/ipv6-parameters
     section "5.a. Header types" specifies:

         00 = Hop-by-Hop Options
         41 = ipv6
         43 = Routing
         44 = Fragment
         51 = Authentication
         60 = Destination Options
         50 = Encapsulating Security Payload
         xx = Upper Layer Header
         58 = Internet Control Message Protocol (ICMP)
         59 - no next header

     Therefore 41, 58, 59 are not provided for in RFC 5102.

     Also, 108 "Payload compression header" is defined in RFC 5102,
     coming from RFC 2393. This is missing from section 5.a of
     http://www.iana.org/assignments/ipv6-parameters.

     Finally, we should define bit 11 for the IPv6 mobility header
     (RFC 3775). ie:

        Bit    IPv6 Option   Description

        11, MOB    135       IPv6 mobility (RFC 3775).

* tcpControlBits

     Identical to RFC 793, so no issue.

* tcpOptions

     While all the text is good, since RFC 791 specifies that "the bit
     labeled 0 is the most significant bit", the diagram depicting the
     bits is reversed. It should be:

               0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           |   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
           +-----+-----+-----+-----+-----+-----+-----+-----+

               8     9    10    11    12    13    14    15
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
           +-----+-----+-----+-----+-----+-----+-----+-----+

              16    17    18    19    20    21    22    23
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
           +-----+-----+-----+-----+-----+-----+-----+-----+

                                 . . .

              56    57    58    59    60    61    62    63
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
           +-----+-----+-----+-----+-----+-----+-----+-----+

Thanks.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.