Subject: draft-conta-ipv6-flow-label-02.txt

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 10 Aug 2001 18:31:40 +0900

with many of the diffserv-oriented encoding, there are possibilities
	for routers to get tricked by originating nodes, leading to theft of
	traffic and/or simple kernel panic (if we put header length into flow
	label field, and if your router is careless - if you are careful you
	are not speeding things up and there's no meaning in embedding
	header length into flow label field).
	I'm not very happy with the proposal.

	I vote for end-to-end pseudorandom value as specified in RFC1883
	(2460 weakened end-to-end part of the text, IIRC).
	it helps you to hash traffic at routers, that's all.
	you cannot trust the value in the field anyways, therefore
	pseudorandom is the only thing you can handle.

itojun
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Sun, 12 Aug 2001 14:50:43 +0300 (EEST)

Hello all,

[ http://www.ietf.org/internet-drafts/draft-conta-ipv6-flow-label-02.txt ]

The ipv6 flow label draft presented at IETF51 generated a lot of
discussion; basically UDP/TCP port numbers and some other data is mapped
into the proposed Flow label field.

The concern on the security, and reliability, of this were raised, and
rightly so (I agree), but IMO the main point is this:

Currently, Edge routers or hosts themselves, set DSCP/Traffic Class bits
in the datagrams after looking at UDP/TCP ports, or some other,
functionally equivalent data.  Traffic class is of limited size and has no
global meaning.

With separate, sufficiently long Flow Label field, DiffServ model _could_
be extended so that the core routers themselves (or Edge/Border routers
mode scalably) could perform classification and differentiation. The data
-> Flow Label mapping only has to be done once, and it's in a fixed
position in the header.  The policy within different AS's, how to deal
with specific packets, could be (mostly) covered.  The packet wouldn't
have to reclassified at the border.

Were it not for reliability, layer violation, the function of core
routers, etc. considerations, this _could_ be viewed as a Good Thing for
enabling easier _Internet-wide_ QoS.  This is perhaps one "justification"
for the author for introducing this behaviour.

Just bringing up one point about DiffServ which was not all that possible
with IPv4..

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords