Re: draft-macaulay-6man-packet-stain-00

Victor Kuarsingh <> Sun, 08 April 2012 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CAC521F853A for <>; Sun, 8 Apr 2012 09:33:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5R3R88sxBro for <>; Sun, 8 Apr 2012 09:33:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A50FC21F8525 for <>; Sun, 8 Apr 2012 09:33:58 -0700 (PDT)
Received: by iazz13 with SMTP id z13so6013652iaz.31 for <>; Sun, 08 Apr 2012 09:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=p0bvhvpKLzzjUEbENDVVvFzeG3eZeBNKVh6RJsrmtug=; b=Kvz50mbdjPJiicAKpLKP4OPDgMFSHZwVHRiwOlatlS214JLjbcurwOT/v8yy/Z5MLW 1gEo7c4z0LICsQz8bowqjGg0sPokESKr85xxOlGNO+P+8xhW9iZRmD95oCaM+ANUngLM DEBMgeByqLpYFYdD5LZ8cBTKd9IuEZ7uhBNsf2agALLHE8j//V6FAp3RdmoiihXWl1E6 fyxoaWw0OtHDL9ee73rgpVi0EGItmj6bXkYJ2fLTGV1KFBzYEYljDcyt5mLrBjqDdVEW QRUKv5kauG/cOjL2dEg7SfoYAFHlkYCTUbAeyQWSu7JgjYN5qcIAzeWkjD2EKxDeEPO7 Jq9Q==
Received: by with SMTP id s1mr3030745igj.45.1333902838333; Sun, 08 Apr 2012 09:33:58 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id df1sm12112659igb.12.2012. (version=SSLv3 cipher=OTHER); Sun, 08 Apr 2012 09:33:57 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/
Date: Sun, 08 Apr 2012 12:33:59 -0400
Subject: Re: draft-macaulay-6man-packet-stain-00
From: Victor Kuarsingh <>
To: Brian E Carpenter <>, Joel jaeggli <>
Message-ID: <>
Thread-Topic: draft-macaulay-6man-packet-stain-00
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 6man <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 08 Apr 2012 16:33:59 -0000

On 12-04-08 3:10 AM, "Brian E Carpenter" <>

>On 2012-04-07 17:17, Joel jaeggli wrote:
>> I hesitate to suggest this because I'll probably turn into a pillar of
>> salt at some point for harping on it. however...
>Just don't look back (towards IPv4).
>> Getting new extension headers generally parsed is a high bar to get
>> over. 
>I have another concern; this draft appears to state that some
>middlebox inserts an extension header into a packet on the fly:
>  "IPv6 packet staining support consists of labeling datagrams with
>   security reputation information through the addition of an IPv6
>   destination option in the packet header by packet manipulation
>   devices (PMDs) in the carrier or enterprise network."
>I'm not aware of any provision in RFC 2460 allowing this, or of any
>other extension header that is inserted by a middlebox. The implications
>for MTU size and fragmentation are clear.

This point was brought up in the WG meeting which noted issues with
fragmentation.  I think it was clear based on numbers folks at the mic
that inserting an extension header mid-stream would result in negative

>> That said within one domain of control you might be able to fit a
>> subset of the information you're looking to carry into the  20 bits
>> available in flow label. 6437 probably provides enough cover/instruction
>> to allow for that.
>Given that the first paragraph of the Introduction to the draft is almost
>identical to the same paragraph in 6437, you may be on to something.
>However, it's only conformant if (a) the resulting values belong to a
>reasonably uniform distribution and are hard to predict and (b) the method
>MUST NOT be used for packets whose flow label is already non-zero.

The point of using the flow label seems valid.  The author will need to
re-evaluate the requirements as I believe it was noted in the WG
presentation that the Flow Label seemed to be too restrictive (size) for
this function (packet staining).  If the staining can be bounded by the
size of the flow label then perhaps the author can re-focus on using it
for this function (packet staining).

Victor K

>    Brian
>IETF IPv6 working group mailing list
>Administrative Requests: