Subject: Flow Label in IPv6 header

From: "Narsimharao Nagampalli" <[email-masked]>
Date: Thu, 01 Jun 2000 05:08:55 -0600

Hi,

Could anyone help me understand the logic behind selecting 20 bit  flow label field in the IPv6 header? 

IPv4 uses the src and dest addr and ports to denote a flow. Ofcourse not necessarily every 4 tuple should map to a flow, but if there was a 32 bit field, we could have right away re-used the src+dest port fields to indicate the flow in IPv6 too.

Firewalls, proxies, L4 switches, QoS mechanisms at routers all need some informaiton on the specific flow to make intelligent decisions. Most them today use transport layer protocol Id and src and destination ports to identify the flow. 

If we provide the src and dest port information in the network layer header itself, these technologies need not violate the layering!

Also if the packets were encrypted as in IPSec, this becomes more so relevant.

May be I am missing some thing here. Would appreciate any clarfications.

Thanks and Regards
Narsi

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "peter@ticl" <[email-masked]>
Date: Mon, 5 Jun 2000 23:24:36 +0100

I think you have answered your own question!!

>IPv4 uses the src and dest addr and ports to denote a flow. Ofcourse not
necessarily every 4 tuple should map to a flow, but if there was a 32 bit
field, we could have right away re-used the src+dest port fields to indicate
the flow in IPv6 too.
>
>Firewalls, proxies, L4 switches, QoS mechanisms at routers all need some
informaiton on the specific flow to make intelligent decisions. Most them
today use transport layer protocol Id and src and destination ports to
identify the flow.
>
>If we provide the src and dest port information in the network layer header
itself, these technologies need not violate the layering!
Yes - that why we have a flow label, or at least partly.

>Also if the packets were encrypted as in IPSec, this becomes more so
relevant.
Yes - thats why we have a flow label, or at least partly.

Think of the overheads required of a firewall/router/etc to parse the
daisy-chained v6 headers in order to find the transport header, and hence
the application identification.  What if this is encrypted inside an ESP
header?

Placing a single flow label in the default v6 header makes these problems
vanish.  You can then decide whether to use just the flow label, or the
label plus src and/or dest IP address to provide your flow based processing.
It seems pretty straightforward to me, but then, as I said above, I think
you answered your own question.

The flow label is 20 bits long because that was all that was left 'spare' in
the header.  (A few iterations ago it was 24 bits, but the new traffic class
field needed another 4 bits when it replaced the older priority field).

Peter

---

From: "Narsimharao Nagampalli" <[email-masked]>
Date: Mon, 05 Jun 2000 22:56:21 -0600

But today we do not define a standard way of creating the flow label and it is also mentioned that flow label is NOT MANDATORY. Now, since most of the technologies liek QoS, IPsec., firewalls etc use the 5 tuple way they would be forced to continue same way until there is a GAURANTEED cheaper alternative.

May be the ISN on the connection or some existing mechanism can be re-used.  I would be not so worried about the exact mechanism to be used as long as it is gauranteed that there would be a proper flow label in the IPv6 header.

-Narsi

>>> "peter@ticl" <[email-masked]> 06/06/00 03:54AM >>>

Peter