Subject: [IPFIX] RFC 5102 diagrams are back to front?

From: Paul Aitken <[email-masked]>
Date: Wed, 23 Jul 2008 14:26:23 +0100

Dear All,

Looking at the RFC 5102 diagrams for the definitions of the following 
elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions

- we appear to have drawn the diagrams back to front :-(

eg, isMulticast is depicted thus:

             0      1      2      3      4      5      6      7
          +------+------+------+------+------+------+------+------+
          | MCv4 | RES. | RES. |  T   |   IPv6 multicFrom [email-masked]  Wed Jul 23 06:25:45 2008
Date: Wed, 23 Jul 2008 14:26:23 +0100
From: Paul Aitken <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [IPFIX] RFC 5102 diagrams are back to front?
Sender: [email-masked]

Dear All,

Looking at the RFC 5102 diagrams for the definitions of the following 
elements: isMulticast, ipv4Options, ipv6ExtensionHeaders, tcpOptions

- we appear to have drawn the diagrams back to front :-(

eg, isMulticast is depicted thus:

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

          Bit  0:    set to 1 if IPv4 multicast
          Bits 1-2:  reserved for future use
          Bit  4:    set to value of T flag, if IPv6 multicast
          Bits 4-7:  set to value of multicast scope if IPv6 multicast

Whereas it should have been drawn thus:

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

- so that MCv4 is in the LSB position, with a value of 1 - rather than a 
value of 128, as currently depicted.

Our implementation uses the LSB for MCv4, per the latter diagram. Has 
anyone implemented this field with MCv4 in the MSB position?

Again, ipv4Options is depicted as:

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

Whereas it should have been drawn thus:

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

Because RFC 791 defines:

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

The latter is trivial to implement as (1 << option_num), whereas what's 
depicted in RFC 5102 would be more complicated to implement.

Has anyone implemented this field yet? Which bits are you using?

Fortunately the depictions of fragmentFlags and tcpControlBits _do_ 
align with the corresponding RFCs.

ie, for fragmentFlags:

RFC 5102:

            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | R | D | M | D | D | D | D | D |
          | S | F | F | C | C | C | C | C |
          +---+---+---+---+---+---+---+---+

RFC 791:

           0   1   2
         +---+---+---+
         |   | D | M |
         | 0 | F | F |
         +---+---+---+

And for tcpControlBits:

RFC 5102:

           0     1     2     3     4     5     6     7
       +-----+-----+-----+-----+-----+-----+-----+-----+
       |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
       +-----+-----+-----+-----+-----+-----+-----+-----+

RFC 793:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Acknowledgment Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Data |           |U|A|P|R|S|F|                               |
    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
    |       |           |G|K|H|T|N|N|                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |         Urgent Pointer        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             data                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two other RFC 5102 diagrams (for mplsTopLabelExp and 
mplsTopLabelStackSection) still need to be verified.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

icast scope    |
          +------+------+------+------+------+------+------+------+

          Bit  0:    set to 1 if IPv4 multicast
          Bits 1-2:  reserved for future use
          Bit  4:    set to value of T flag, if IPv6 multicast
          Bits 4-7:  set to value of multicast scope if IPv6 multicast

Whereas it should have been drawn thus:

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

- so that MCv4 is in the LSB position, with a value of 1 - rather than a 
value of 128, as currently depicted.

Our implementation uses the LSB for MCv4, per the latter diagram. Has 
anyone implemented this field with MCv4 in the MSB position?

Again, ipv4Options is depicted as:

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

Whereas it should have been drawn thus:

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

Because RFC 791 defines:

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

The latter is trivial to implement as (1 << option_num), whereas what's 
depicted in RFC 5102 would be more complicated to implement.

Has anyone implemented this field yet? Which bits are you using?

Fortunately the depictions of fragmentFlags and tcpControlBits _do_ 
align with the corresponding RFCs.

ie, for fragmentFlags:

RFC 5102:

            0   1   2   3   4   5   6   7
          +---+---+---+---+---+---+---+---+
          | R | D | M | D | D | D | D | D |
          | S | F | F | C | C | C | C | C |
          +---+---+---+---+---+---+---+---+

RFC 791:

           0   1   2
         +---+---+---+
         |   | D | M |
         | 0 | F | F |
         +---+---+---+

And for tcpControlBits:

RFC 5102:

           0     1     2     3     4     5     6     7
       +-----+-----+-----+-----+-----+-----+-----+-----+
       |  Reserved | URG | ACK | PSH | RST | SYN | FIN |
       +-----+-----+-----+-----+-----+-----+-----+-----+

RFC 793:

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          Source Port          |       Destination Port        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Sequence Number                        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Acknowledgment Number                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Data |           |U|A|P|R|S|F|                               |
    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
    |       |           |G|K|H|T|N|N|                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |           Checksum            |         Urgent Pointer        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Options                    |    Padding    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                             data                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two other RFC 5102 diagrams (for mplsTopLabelExp and 
mplsTopLabelStackSection) still need to be verified.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Paul Aitken <[email-masked]>
Date: Wed, 30 Jul 2008 12:36:08 +0100

Dear All,

I didn't see any reply to this issue on the mailing list, nobody 
mentioned it in the IPFIX WG meeting, and nobody discussed the issue 
with me here in Dublin.

So I'm not sure whether to conclude that nobody implemented these fields 
yet, or just that nobody understood the issue?

What I propose is to deprecate the isMulticast and ipv4Options fields in 
favour of new IEs with similar definitions, except that the bit order is 
reversed as shown below.

Does anyone disagree?

P.

>          | MCv4 | RES. | RES. |  T   |   IPv6 multicast scope    |

---

From: Paul Aitken <[email-masked]>
Date: Wed, 30 Jul 2008 12:36:08 +0100

Dear All,

Does anyone disagree?

P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Jul 2008 13:34:44 +0100

Paul, all,

This would seem to be the correct, indeed probably the only, thing to  
do.

The naming of these new IEs could prove problematic, though. I'd  
prefer to avoid the drifting-API idiom of sticking numbers on (e.g.,  
ipv6ExtensionHeaders2) -- what should we do about this?

Cheers,

Brian

On Jul 30, 2008, at 12:36 PM, Paul Aitken wrote:

> So I'm not sure whether to conclude that nobody implemented these  
> fields yet, or just that nobody understood the issue?
>
> What I propose is to deprecate the isMulticast and ipv4Options  
> fields in favour of new IEs with similar definitions, except that  
> the bit order is reversed as shown below.
>
> Does anyone disagree?
>
> P.
>
>> Looking at the RFC 5102 diagrams for the definitions of the  
>> following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders,  
>> tcpOptions
>> eg, From [email-masked]  Wed Jul 30 05:35:04 2008
From: Brian Trammell <[email-masked]>
To: Paul Aitken <[email-masked]>
Date: Wed, 30 Jul 2008 13:34:44 +0100
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [IPFIX] RFC 5102 diagrams are back to front?
Sender: [email-masked]

Paul, all,

This would seem to be the correct, indeed probably the only, thing to  
do.

The naming of these new IEs could prove problematic, though. I'd  
prefer to avoid the drifting-API idiom of sticking numbers on (e.g.,  
ipv6ExtensionHeaders2) -- what should we do about this?

Cheers,

Brian

On Jul 30, 2008, at 12:36 PM, Paul Aitken wrote:

> So I'm not sure whether to conclude that nobody implemented these  
> fields yet, or just that nobody understood the issue?
>
> What I propose is to deprecate the isMulticast and ipv4Options  
> fields in favour of new IEs with similar definitions, except that  
> the bit order is reversed as shown below.
>
> Does anyone disagree?
>
> P.
>
>> Looking at the RFC 5102 diagrams for the definitions of the  
>> following elements: isMulticast, ipv4Options, ipv6ExtensionHeaders,  
>> tcpOptions
>> egisMulticast is depicted thus:
>>            0      1      2      3      4      5      6      7
>> - so that MCv4 is in the LSB position, with a value of 1 - rather  
>> than a value of 128, as currently depicted.
>> Our implementation uses the LSB for MCv4, per the latter diagram.  
>> Has anyone implemented this field with MCv4 in the MSB position?
>> The latter is trivial to implement as (1 << option_num), whereas  
>> what's depicted in RFC 5102 would be more complicated to implement.

, isMulticast is depicted thus:
>> - so that MCv4 is in the LSB position, with a value of 1 - rather  
>> than a value of 128, as currently depicted.
>> Our implementation uses the LSB for MCv4, per the latter diagram.  
>> Has anyone implemented this field with MCv4 in the MSB position?
>> The latter is trivial to implement as (1 << option_num), whereas  
>> what's depicted in RFC 5102 would be more complicated to implement.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 30 Jul 2008 14:25:04 +0100

Brian,

> This would seem to be the correct, indeed probably the only, thing to do.
> 
> The naming of these new IEs could prove problematic, though. I'd prefer 
> to avoid the drifting-API idiom of sticking numbers on (e.g., 

We could potentially keep the same name, since the IDs would be 
different. However, that could potentially lead to confusion, eg if two 
implementations both claim to export "isMulticast" yet one uses the 
deprecated definition.

Some potential options are: to append a version number (eg, 
"isMulticast-2") or a date (eg, "isMulticast-0808"), or most obviously, 
to pick more appropriate names.

eg, "isMulticast" implies a boolean; perhaps it should become 
"multicastInfo" due to the other fields it also contains. However, I'm 
not so sure how best to rename ipv4Options.

However, new names are unnecessary if no-one is already implementing 
these fields... we would simply deprecate the existing definitions and 
create new ones which the first implementations would use.

---

From: Paul Aitken <[email-masked]>
Date: Wed, 30 Jul 2008 14:25:04 +0100

Brian,

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Jul 2008 14:32:55 +0100

Paul,

On Jul 30, 2008, at 2:25 PM, Paul Aitken wrote:

>> prefer to avoid the drifting-API idiom of sticking numbers on  
>> (e.g., ipv6ExtensionHeaders2) -- what should we do about this?
>
> different. However, that could potentially lead to confusion, eg if  
> two implementations both claim to export "isMulticast" yet one uses  
> the deprecated definition.

Though I suppose 5102 does not explicitly disallow it, I'm really,  
really leery of having two IEs with the same name in the registry. The  
potential for confusion is absolute.

> "isMulticast-2") or a date (eg, "isMulticast-0808"), or most  
> obviously, to pick more appropriate names.
>
> "multicastInfo" due to the other fields it also contains. However,  
> I'm not so sure how best to rename ipv4Options.
>
> these fields... we would simply deprecate the existing definitions  
> and create new ones which the first implementations would use.

Would this require an errata document to 5102, or could we just fix  
the descriptions in the IANA registry?
_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Brian Trammell <[email-masked]>
Date: Wed, 30 Jul 2008 14:32:55 +0100

Paul,