Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

Joe Touch <> Mon, 18 June 2012 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9716A21F8657 for <>; Mon, 18 Jun 2012 11:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.099
X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 04BWdhuyLB8J for <>; Mon, 18 Jun 2012 11:58:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2239C21F85B5 for <>; Mon, 18 Jun 2012 11:58:45 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q5IIw2VP026235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 18 Jun 2012 11:58:03 -0700 (PDT)
Message-ID: <>
Date: Mon, 18 Jun 2012 11:58:02 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Masataka Ohta <>
Subject: Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Jun 2012 18:58:45 -0000

On 6/18/2012 5:09 AM, Masataka Ohta wrote:
> Joe Touch wrote:
>>> 	draft-generic-v6ops-tunmtu-03.txt
>>> to fragment IPv6 packets by intermediate routers should be
>>> very interesting to you.
>> It is aware of our IPv4-ID doc, and consistent with it.
> What?

I looked more closely, and the doc is deeply flawed, even though it
appears to intend to be consistent with our IPv4-update doc through rate
limiting.  I'll post a summary to the v6-ops mailing list of those
issues. To summarize:

- it fragments inner packets at the ingress but does not reassemble them
	this means its choice of unique IDs isn't unique; other
	paths that don't use the tunnel might have IDs that
	are set by the source that collide with those assigned
	by the ingress, causing reassembly errors

- it creates inner fragments that interfere with arriving fragments
	i.e., it claims the IDs are unique, but this is true only
	for those it assigns; it does not attempt to monitor or
	drop collisions due to fragments that arrive with
	recently assigned IDs

>> When the DF is "ignored", the ID field is rewritten - i.e.,
> If the ID field could be rewritten by intermediate entities,
> it is fine for intermediate routers to clear DF.

The counterexample is, as above:

	- when source-generated fragments can go around the rewriter

	- when other rewriters exist on other paths

Any time this sort of rewriting occurs, it might be safe if contained
inside a tunnel that "cleans up its mess", i.e., when it knows that only
its ingrees can generate fragments, and that the egress reassembles the
fragments and sets the DF=1.

Since that's not the case here, it's not safe.