Subject: Re: Usage of IPv6 flow label

From: Jim Bound <[email-masked]>
Date: Fri, 01 Dec 2000 11:23:09 -0500

brian,

just as a note I don't believe we need to know port numbers and this
should have never been done except for ALGs.  I do not think we should
keep such nonsense continued in IPv6.  

/jim
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2000 14:35:34 -0600

But Jim, this is how QOS works. Diffserv was carefully designed to be
identical for IPv4 and IPv6 (we thought you'd be pleased :-)

  Brian

---

From: Jim Bound <[email-masked]>
Date: Sun, 03 Dec 2000 23:24:30 -0500

Hi Brian,

>identical for IPv4 and IPv6 (we thought you'd be pleased :-)

I am pleased with the diff serv bits and that they work with IPv4 and
IPv6.  Its the assumptions after the bits are set that may have me
concerned.  I think QOS is an over used and abused term.  I think
discussing diff serv and int serv is goodness.  int serv is my agenda
not messing up diff serv.

But if diff serv depends on extracting layer 4 information as a manner
of standard then I think they went off the edge, "literally" :---).

Another option for products that want to look at layer 4 information is
to define a new destination option.  One can put whatever they want in
those.

/jim

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Dec 2000 10:03:01 +0100

In your previous mail you wrote:

=> this idea is not so silly if this destination option is at the new
position, ie. between the routing header and the fragment header.
This will solve the fragment classification issue (to keep some state
works only if fragments are in the suitable order, at least one common OS
sends to last fragment first). Of course an encapsulation device can
repeat it in the outer header (like tunnel encapsulation limit option).

[email-masked]

PS: I prefer this solution than to hack some bits in the flowlabel.
I'd like to have Thomas Eklund's opinion (ie. is to chase for this
option easy enough?)
--------------------------------------------------------------------
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: [email-masked]
Date: Mon, 04 Dec 2000 18:11:17 +0900

>repeat it in the outer header (like tunnel encapsulation limit option).

	the option was explored a bit in ipsec working group (NAT-friendly
	ipsec proposal).  not sure about the current status, or security
	implication/threat model (for example, if I were an attacker, I'd
	try to sniff/decrypt traffic with a port # for banking transaction!).

itojun

---

From: Francis Dupont <[email-masked]>
Date: Mon, 04 Dec 2000 10:22:10 +0100

=> a security gateway can or copy the header or hide it. It can apply
its policy with the whole information (ie. it has the header then it knows
what information it will reveal). I think it is the best compromise
between security and classification... Of course I assume the security
gateway is clever (if it is dumb you can remove the security :-).

Regards

PS: in fact the security issue is the same than with flow label hacking,
but an option is cleaner then should be better from any point of view...
--------------------------------------------------------------------
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: Brian E Carpenter <[email-masked]>
Date: Mon, 04 Dec 2000 11:24:43 -0600

Yes, I agree that this is interesting and it would allow us to treat
the flow label as an opaque binary string in all cases.

  Brian