Subject: [IPFIX] IPFIX fragmentIdentification

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 11:16:04 +0100

IPFIX fragmentIdentification is defined as:

   The value of the Identification field in the IPv4 packet header or the
   IPv6 Fragment header, respectively. The value is 0 for IPv6 if there
   is no Fragment header.

So the IPv4 ID and IPv6 fragmentation ID are combined in a single field.

RFC 791 shows the IPv4 Identification is 16 bits:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |Version|  IHL  |Type of Service|          Total Length         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Identification        |Flags|      Fragment Offset    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Whereas RFC 2460 shows the IPv6 ID is 32 bits:

     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Identification                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to 
extend the IPv4 ID to 32 bits.

Seems that it would be more correct to have two different IDs for these?

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

_______________________________________________
IPFIX mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipfix

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 02 Oct 2006 16:38:28 +0200

Hi Paul,

--On 02.10.2006 11:16 Uhr +0100 Paul Aitken wrote:

> So if we're using this field for mixed IPv4/IPv6 traffic, we'd need to extend the IPv4 ID to 32 bits.

Or you use different templates for v4 and v6.  This is anyway preferable
if you include more header fields, and required if you include IP addresses.

> Seems that it would be more correct to have two different IDs for these?

I consider cases where you need them separate to be rare, but I do not have a
problem with adding special IEs for v4 and v6.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 02 Oct 2006 16:38:28 +0200

Hi Paul,

Thanks,

    Juergen

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 15:46:22 +0100

Juergen,

> if you include more header fields, and required if you include IP 

Suppose you don't know (and don't especially care) whether it's IPv4 or 
IPv6 traffic? For some reason you're just monitoring the IDs.

> I consider cases where you need them separate to be rare, but I do not 
> have a problem with adding special IEs for v4 and v6.

I think I would prefer to go back to #54 = IPv4 ID (coming from the 
netflow v9 definition) and create a new fragmentIdentificationIPv6 IE.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 02 Oct 2006 15:46:22 +0100

Juergen,

---

From: Lutz Mark <[email-masked]>
Date: Mon, 09 Oct 2006 17:24:39 +0200

> netflow v9 definition) and create a new fragmentIdentificationIPv6 IE.

I support this. We had this discussion before:
http://www1.ietf.org/mail-archive/web/ipfix/current/msg03259.html

I still prefer to use a name that
makes it clear that this info is
part of the IPv6 extension header.

Best regards,
Lutz

---

From: Lutz Mark <[email-masked]>
Date: Mon, 09 Oct 2006 17:24:39 +0200

Best regards,
Lutz

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 10:00:26 +0200

Paul and Lutz,

Here is a brief summary of the situation so far.

We have three IEs related to fragmentation:

#54  fragmentIdentification unsigned32 
#88  fragmentOffset unsigned16 
#197 fragmentFlags unsigned8 
  
Currently, all three can be used for IPv4 as well as for IPv6.

Now, you request to split fragmentIdentification into two IEs,
one specific for IPv4 and one for specific for IPv6.

The only argument for this that I read so far is saving bandwidth
if you have to report mixed traffic with IPv4 and IPv6, because
the pure IPv4 identifier has half the length of the IPv6 identifier.

Still I do not get this argument:

  1. If you have only IPv4 traffic, you can use reduced encoding and
     waste no bandwidth.

  2. If you report IPv6 traffic only, there is no issue.

  3. If you report mixed traffic, then the current IEs give you two
     options:
     a) Either use a single template for reporting IPv4 and IPv6.
        This implies a waste of 16 bits per IPv4 record
     b) You use different templates for IPv4 and IPv6 records.
        Then you would use 16 bit encoding for the IPv4 record
        and 32 bit encoding for the IPv6 record.

If we split fragmentIdentification into fragmentIdentificationIPv4
and fragmentIdentificationIPv6, then the only achievement would be
that 3.a) is not possible anymore.

Is this what you want to achieve or am I somehow mistaken?
Are there other arguments for the split that I have ignored?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Sun, 15 Oct 2006 10:00:26 +0200

Paul and Lutz,

  

Thanks,

    Juergen

---

From: Brian Trammell <[email-masked]>
Date: Mon, 16 Oct 2006 09:25:09 -0400

Juergen,

Part of this issue would appear to be a specific case of a general  
question - should there be one or two IEs for IPv4/IPv6 header fields  
that are semantically identical and similar in encoding (e.g. DSCP),  
and I thought the direction we were moving in this summer was toward  
_not_ differentiating v4 and v6.

My personal preference would be not to split, and to allow reduced- 
length encoding for fragmentOffset.

Regards,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Mon, 16 Oct 2006 09:25:09 -0400

Juergen,

Regards,

Brian

---

From: Paul Aitken <[email-masked]>
Date: Mon, 16 Oct 2006 17:55:45 +0100

Brian,

> length encoding for fragmentOffset.

I agree with you when the fields are similar.

But since these fields come from different headers (IPv4 header versus 
IPv6 option) and are different sizes (16 bits for IPv4 versus 32 bits 
for IPv6) we concluded that they're not the same and so should have 
different IEs.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 16 Oct 2006 17:55:45 +0100

Brian,