Subject: [ipfix] IPFIX INFO draft

From: Paul Aitken <[email-masked]>
Date: Thu, 25 Aug 2005 15:27:47 +0100

Jeurgen,

5.3.29  headerLengthIPv4

    Description:
       The length of the IPv4 header.
    Abstract Data Type: octet
    ElementId: 207
    Status: current
    Units: octets
    Reference:
       See RFC 791 for the specification of the IPv4 header.

Can we change the units of this to 32 bit words, since that's how IHL is 
defined in the IPv4 header?

5.3.30  packetLengthIPv4

    Description:
       The total length of the IPv4 packet.
    Abstract Data Type: unsigned16
    ElementId: 190
    Status: current
    Units: octets
    Reference:
       See RFC 791 for the specification of the IPv4 total length.

If this is the total length field from the IPv4 header, then shouldn't 
we call it totalLengthIPv4 ?

5.7.5  ipv4Options

    Abstract Data Type: unsigned64
    Data Type Semantics: flags
    ElementId: 208

Can we insert a diagram and table, similar to ipv6OptionHeaders #64?

Finally, what's happening with #204, #205 and #206?

   o  Are we leaving them undefined?
      If so, are they available for new elements,
      or are they reserved?

   o  Or should we move #207 to #210 down, so there's no gap?

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

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 29 Aug 2005 15:54:32 +0200

Hi Paul,

Thanks for the suggestions.  Please find some replies inline.

> defined in the IPv4 header?

If we do so, we should mention the unit explicitly in the description,
because in all other cases, we use octet a unit for IEs indicating a length.

Are there any objections to Paul's proposal?

> we call it totalLengthIPv4 ?

Yes, it is.
I am also fine with the name you suggest.

> Can we insert a diagram and table, similar to ipv6OptionHeaders #64?

Yes.  Can you provide them?

>    o  Or should we move #207 to #210 down, so there's no gap?

I have a clear preference for the second option.
Would you be fine with it?

> Cheers.

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: Paul Aitken <[email-masked]>
Date: Mon, 29 Aug 2005 15:20:44 +0100

Juergen,

> Yes.  Can you provide them?

No I cannot, because the definition does not make sense to me!

The [INFO] text is clear:

     Options are mapped to bits according to their option numbers.
     Option number X is mapped to bit X.

However, looking at http://www.iana.org/assignments/ip-parameters, I see 
a (sparse) list of 25 options numbered from 0 through 205.

Since RFC 791 defines:

     The option-type octet is viewed as having 3 fields:

       1 bit   copied flag,
       2 bits  option class,
       5 bits  option number.

it seems to me that [INFO] requires a 256 bit field.

However, [INFO] has:

So I simply don't understand how this object works.

> Would you be fine with it?

I would, provided it's done immediately and announced widely and clearly 
- because everyone who already has any IPFIX implimentation MUST 
immediately renumber their #207 - #210.

Some people might object to that, and feel it's better to keep the 
existing numbering and simply reuse #204 - #206 for new elements. I 
would also be happy with that solution.

Renumbering is better for a clean draft. However, leaving a gap seems 
technically preferable.

Cheers.

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 30 Aug 2005 16:21:39 +0200

Paul,

> a (sparse) list of 25 options numbered from 0 through 205.

I assume that your browser badly formats the table of the IANA web page.
The column for option numbers is ordered from 0 to 24 and has no gaps.

> it seems to me that [INFO] requires a 256 bit field.

The option type octet has the structure that you described.
However, for identifying an IPv4 option, only the 5-bit option
number is relevant.

> So I simply don't understand how this object works.

The data type has 64 bits. Currently, 25 (0-24) of them are already
assigned by the IETF and more might come in the future.  The current idea
is to use the option number for indexing a bit position in the unsigned64
value.  This maps all 25 already defined IPv4 options and leaves spaces for
39 further ones.

> immediately renumber their #207 - #210.

Please note that still the IESG review might result in protocol changes.
Everybody who already has an IPFIX implementation should be aware that
this implementation is pre-standard as long as the RFC is published.
Consequently, he/she should consider potential protocol changes until
RFC publication in her/his plans.  (Probably it is reasonably safe to
consider the protocol stable after it entered the RFC editor queue.)

> Renumbering is better for a clean draft. However, leaving a gap seems

I do not have a real problem with leaving a gap and filling it later.
But if we leave it, we should add a statement to the info model draft on
why there is a gap.  Otherwise, I expect comments on the gap from the IESG.

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Wed, 31 Aug 2005 14:20:20 +0100

Juergen,

> The column for option numbers is ordered from 0 to 24 and has no gaps.

OK, I see.

> value.  This maps all 25 already defined IPv4 options and leaves spaces for

While this is sufficient for encoding valid options, it is quite 
insufficient for truly reporting real traffic, because someone could 
easily craft some traffic with an option set to copy=0, class=0, 
number=2 (ie, value=2).

How then would I report this?

If I strip out the copy and class info, and only regard the option 
number, then I will incorrectly report it as a security option (which is 
similar, except copy=1 so value=130).

If I'm diligent, perhaps I will realise that only an option with a value 
of 130 should cause bit 2 to be set, so I won't set bit 2 for an option 
with the value of 2, 32+2, 64+2, or 96+2. But this is a complicated mapping.

So I propose that we change the name from "ipv4Options" to 
"ipv4OptionsNumber" and simply encode the 5 bit option number, 
regardless of the "copy" or "class" bits. Then it's clear from the name 
exactly what we're doing. Besides, the text should also clearly state 
this too.

Later, if someone really does need to differentiate the copy, class and 
number bits, then we can create an unsigned256 ipv4Options element.

The table for ipv4OptionsNumber is:

    Number  Name				
    ------  -------------------------------
       0    EOOL   - End of Options List
       1    NOP    - No Operation
       2    SEC    - Security
       3    LSR    - Loose Source Route
       4    TS     - Time Stamp
       5    E-SEC  - Extended Security
       6    CIPSO  - Commercial Security
       7    RR     - Record Route
       8    SID    - Stream ID
       9    SSR    - Strict Source Route
      10    ZSU    - Experimental Measurement
      11    MTUP   - MTU Probe
      12    MTUR   - MTU Reply
      13    FINN   - Experimental Flow Control
      14    VISA   - Expermental Access Control
      15    ENCODE - ???
      16    IMITD  - IMI Traffic Descriptor
      17    EIP    - Extended Internet Protocol
      18    TR     - Traceroute
      19    ADDEXT - Address Extension
      20    RTRALT - Router Alert
      21    SDB    - Selective Directed Broadcast
      22    NSAPA  - NSAP Addresses
      23    DPS    - Dynamic Packet State
      24    UMP    - Upstream Multicast Pkt.

And so the diagram is:

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

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

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

            24     25     26     27     28     29     30     31
         +------+------+------+------+------+------+------+------+
         | UMP  |                    Reserved                    |
         +------+------+------+------+------+------+------+------+

         .                                                       .
         .                                                       .
         .                                                       .

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

>>> Would you be fine with it?

As per another email I sent earlier today, I propose to keep #207 to 
#210 unchanged since I believe this is the best solution for everyone.

Cheers.