IETF Logo Mail Archive

Extracting the 5-tuple from IPv6 packets

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 14 April 2010 22:26 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9822C3A68EE for <ipv6@core3.amsl.com>; Wed, 14 Apr 2010 15:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.346
X-Spam-Level:
X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=0.253, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4MltNL97adi for <ipv6@core3.amsl.com>; Wed, 14 Apr 2010 15:26:20 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 96D263A67F3 for <ipv6@ietf.org>; Wed, 14 Apr 2010 15:26:20 -0700 (PDT)
Received: by pvf33 with SMTP id 33so453447pvf.31 for <ipv6@ietf.org>; Wed, 14 Apr 2010 15:26:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:content-type :content-transfer-encoding; bh=VcaVkol3XNil0FSdYDuH7hkj4PlPYEanwo/DlvWkKnY=; b=Bo34J2lf5IeAK5tAFhVc22R0tm1Nz2po5MwDdLk1i52gZfg8UPPgwTvxK8CLA4nlYM NNGQ6lbYhK3CN8/3W2EVx+2O1idWotWd4q3Ca3lIaEwgZPN46r7xsl7pI9+IMApG6aqw bZy9tfOPVPWyAzEwWfSV8o2QbeNp8FROUu/dc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:content-type:content-transfer-encoding; b=BsOKaORSq0//zBP1LDurSZvIMDBFNNPWX2NwAL2FLAwyDuY9ndAS2ouzkN9z4UldTP VtxkpJFa600oxlKN9ay5VdorgmjiGPb0Fk60LmZfsAevkRnmvXHjBKzW8qNizN2pKqZb yqwmY4PN68beCpz3e8FuE2dIduBFwu1oM5Oh0=
Received: by 10.114.187.11 with SMTP id k11mr7902701waf.153.1271283972002; Wed, 14 Apr 2010 15:26:12 -0700 (PDT)
Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 22sm675395pzk.5.2010.04.14.15.26.10 (version=SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 15:26:11 -0700 (PDT)
Message-ID: <4BC64100.303@gmail.com>
Date: Thu, 15 Apr 2010 10:26:08 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: 6man <ipv6@ietf.org>
Subject: Extracting the 5-tuple from IPv6 packets
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: Nevil Brownlee <n.brownlee@auckland.ac.nz>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Apr 2010 22:26:21 -0000

Hi,

Common practice in network monitoring and in QoS technologies
is to identify a flow of packets by the 5-tuple
{source address, dest address, source port, dest port, protocol #}.
This is relatively trivial at line speed in IPv4 since
these things are at fixed locations in the header. But in IPv6,
the protocol number is at the end of a linked list of "next
headers." Even if the normal case is only one item in the linked
list, any implementation (hardware or software) that extracts
the 5-tuple has to follow the linked list to the end.

As Mark Smith said in relation to draft-carpenter-6man-flow-update-02

>> Secondly, for IPv6 packets with a number of extension headers before
>> the transport layer header, I think this rule could impact forwarding
>> performance. While I'm not sure if it is that practical, however it'd
>> be good if flow classification could be done using only fixed headers
>> in the IPv6 packet, or a fixed portion of the fixed header bits.

The problem is, only the protocol number is diagnostic of an individual
flow. The earlier next headers are not guaranteed to be the same for
all packets in a transport session, and they might be the same for packets
in different transport sessions between the same two hosts.

So it seems to me that we are stuck with identifying IPv6 flows by
the 5-tuple, even though it means following the linked list to the
end. Or we can forget about identifying individual transport flows,
and identify all traffic between the same two hosts via the 4-tuple
{source address, dest address, source port, dest port}.

Or we can strongly recommend that all hosts set the flow label, so
that we can use the 3-tuple {source address, dest address, flow label}.

What do people think?

-- 
Regards
   Brian Carpenter

v2.23.0 | Report a Bug | By Email