Re: AD review of draft-ietf-6man-flow-update

RJ Atkinson <rja.lists@gmail.com> Tue, 21 June 2011 13:03 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AEC11E810C for <ipv6@ietfa.amsl.com>; Tue, 21 Jun 2011 06:03:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.556
X-Spam-Level:
X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzmTryBG5oTo for <ipv6@ietfa.amsl.com>; Tue, 21 Jun 2011 06:03:56 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92E4711E8107 for <ipv6@ietf.org>; Tue, 21 Jun 2011 06:03:56 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2511394qyk.10 for <ipv6@ietf.org>; Tue, 21 Jun 2011 06:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=S7WxKGpqIS1E2++wKbGQ1K7nweEHleQtAWc64JywwbM=; b=Fr+HKzctYwdeL26qF0KIUKCD+Xn+kz0YvqytY6hDvtwY3eeWW74h8PX2K+/NP4vykc DhW0tVRNREofMG+e1SemBwiEsKsZQQvJSieeASoStRs2IC80Xnt04TLGN9GSjsqkvlLj zF9cOQcJldXnRP6edzI+Z4fxLiMsj+oTjHzCo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=oGW0/8DuBrY8BHOnfxZv8ao//fCt15CHOFAL0+5z3/V1czms2jZRifktI9BwOAcefl kgCASLE2M0ktLGwi0cxnMANHuyoZc4TJ6UurBRdUtIzcj01Rafnd/q+4czIktqRJRzEM b+xgS57ZSzcSBbxXv5HY1xXm6KLrQ7NktiqWI=
Received: by 10.224.207.131 with SMTP id fy3mr4905477qab.89.1308661436083; Tue, 21 Jun 2011 06:03:56 -0700 (PDT)
Received: from [10.30.20.12] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id g7sm1058241qck.44.2011.06.21.06.03.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:03:55 -0700 (PDT)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: AD review of draft-ietf-6man-flow-update
Date: Tue, 21 Jun 2011 09:03:54 -0400
Message-Id: <023C12B3-CBC6-4406-82FE-ED7707ACE7A6@gmail.com>
To: ipv6@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 21 Jun 2011 13:03:57 -0000

Earlier, Brian Carpenter wrote:
> I'd have to trawl the archive to find all the arguments,
> but the main issue was that any attempt to include semantics
> in the bits of the flow label leads to complexity that
> probably can't be handled at line speed in a scaleable way.

That claim presumes that a typical IPv6 router is using CPU-based
packet forwarding.  I believe that assumption to be incorrect.
(By the way, this assumption underlies a lot of the discussion
on the IPv6 list.  Those of us who build ("have built", in my own 
case) real routers try to speak up about this from time to time,
apparently without having much impact on WG thinking.

I believe that most deployed IPv6 routers are using ASIC-based
or FPGA-based forwarding of IPv6 packets.  NP-based forwarding
is not uncommon, but is probably less common.  An advantage
of NP-based forwarding engines or FPGA-based forwarding engines
is that new capabilities can be added on the fly.  While some
deployed ASIC-based forwarding engines are programmable, most 
IPv6-capable ASIC forwarding engines are not programmable.

Even the really low-cost consumer electronics routers that 
support IPv6 generally do so via commodity silicon packet 
processors offered by a range of different merchant silicon 
firms based in various countries (example: Broadcom).

Since the majority of the lifespan of IPv6 is well into the 
future, and deployment today remains pretty small today,
compared with say 3 years from now, re-allocating those 4 bits 
seems entirely possible to me.

> Also 16 bits might make it too easy for a malicious party
> to predict flow label values.

That makes no mathematical sense to me.

To the extent 16 bits is problematic, 20 bits also would be
problematic.  So that argument also does not make sense to me.
Even if someone has formal maths behind that claim, which so far
I haven't seen claimed on the IPv6 WG list, Moore's Law would
defeat any claim that 20 bits is adequate within ~5 years.

Yours,

Ran