Re: TSVART review of draft-ietf-6man-deprecate-atomfrag-generation

Brian E Carpenter <> Mon, 29 August 2016 22:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8425612D8A9; Mon, 29 Aug 2016 15:50:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qvOAlG_4IjEG; Mon, 29 Aug 2016 15:50:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA0A712D8B8; Mon, 29 Aug 2016 15:50:03 -0700 (PDT)
Received: by with SMTP id ci2so631047pad.3; Mon, 29 Aug 2016 15:50:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=4XL/4jlpxG2X/R/Md+DcVakCDkXRbeCip9Rze/t3mZQ=; b=o8WfhuKeiv44AnIlpiqf+0KQJHbr/f7nU8L90RZSXUMg3h9WoqDy9NDRAtBQr9rm5d CibklMLsANTGvCWOdM054M8WnyAf3jQbjOgqWTXixQTfxCN7buu8gzbammpfVOhsyHPc Yr9wZFgJdPH8RbxCUtf+teoxRQMzus4Zeg/njl6qwTYGR1kd9/miIEurD4wCLWrtdPgT GfopviiqB+I0SexnjNwXJF3d/vhvAOzgkaAdNKcf0v+1SAj6Air2HX7RI9Yu4boI2Goq XCKq+Cs32plInXqllFcDWf+LtRLg3q/FPNiyUyACR0pHVwlnw5aXVIqacvvx42gdb6p6 jYVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=4XL/4jlpxG2X/R/Md+DcVakCDkXRbeCip9Rze/t3mZQ=; b=ZVpq4ag38/Hwu5TZn8tyeZY9UBgLzPTFVDMTWMgzgAZWrfgjz8fIeR1csHzMjUli7U +7+I4Py/NaoXZcBTSGd9knfOiH2vTXaqo4Z9xOn2GYEq2kVkSrwIWf+2sXb8H2cvilfL odXqi/Dprp98T/S/xEHzN4KfzJ5dDfw5tdZuVBAvABGA7NT5ISXw56Jo9VantsXd8aEl QoRIQbrzIFsqHOSYN/iEGSDoBNsoXn+Qf4LrwAa1HgNpcZFWpAbt2+yCi7R614iEml6J kgF9egt1CtmWiBIeGYGSSILW6A+2GYIieYls209iUyExVsbpgFF8SGA33DRJ5Jj5xpuj x1YA==
X-Gm-Message-State: AE9vXwN+TGOsykNewTbrQwR3laRuIIIaOPVLsR4HFo783pEZCT0c7EwiuGypUNXuCmADig==
X-Received: by with SMTP id dd10mr718783pad.152.1472511003053; Mon, 29 Aug 2016 15:50:03 -0700 (PDT)
Received: from ?IPv6:2001:df0:0:2006:c0da:ac17:5f6d:8e76? ([2001:df0:0:2006:c0da:ac17:5f6d:8e76]) by with ESMTPSA id n10sm51712132pap.16.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 15:50:02 -0700 (PDT)
Subject: Re: TSVART review of draft-ietf-6man-deprecate-atomfrag-generation
To: Joe Touch <>, Fernando Gont <>, 6man <>
References: <> <> <> <> <>
From: Brian E Carpenter <>
Organization: University of Auckland
Message-ID: <>
Date: Tue, 30 Aug 2016 10:50:01 +1200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, Transport Area <>,, IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Aug 2016 22:50:30 -0000

On 30/08/2016 10:14, Joe Touch wrote:
> Hi, Fernando,
> On 8/29/2016 3:05 PM, Fernando Gont wrote:
>> On 08/28/2016 01:33 PM, Joe Touch wrote:
>>> Hi, Fernando,
>>> First, I'd like to note something more important about this doc - the
>>> abstract itself argues that this change should update the core IPv6
>>> spec. Given that is already well underway, why is this document even
>>> needed?
>> The document says it clearly: "documenting the
>>    motivation for removing this functionality in the revision of the
>>    core IPv6 protocol specification."
>> You just don't remove a feature from a spec silently, without a
>> rationale. And the place to include the rationale wasn't rfc2460bis --
>> hence this dcument.
> I don't agree. RFC2460bis should not need a roadmap to explain all of
> the associated changes and their rationales. That should be in 2460bis.

2460bis has pointers in such cases (and should include a pointer
to deprecate-atomfrag when it becomes an RFC). I don't think it is
helpful to readers of 2460bis to burden it with all the rationales.

> Otherwise, changes need to be made incrementally - that's a lot of extra
> load on the IETF and a lot of complexity to figure out why things are
> the way the end up.

I don't think 2460bis will be the end of history, any more than 791 was
the end of IPv4 history. Incremental change will continue.


>>>>> The impact of this change does not appear to have been explored. Section
>>>>> 3 ends with a claim that links where this translation issue would be a
>>>>> problem are rare, but there is no evidence presented as to whether
>>>>> current RFC 6145 translators would be capable of complying with the
>>>>> changes in this doc, e.g., to be able to generate IPv4 IDs as needed.
>>>>> I.e., this document needs to update RFC6145 Sec 5.1 to require that IPv4
>>>>> ID generation MUST be supported (and used), rather than MAY.
>>>> RFC 6145 has been revised as RFC7915.
>>> The second sentence of this draft cites 6145. You raise a good point,
>>> but given 7915 obsoletes 6145 (rather than updating it), all references
>>> throughout should then refer to 7915 instead.
>> Not really. We're documenting why this feature is being removed -- hence
>> there's a place for referencing RFC6145 ("state of affairs before any
>> updates") and RFC7915.
>> All references to RFC6145 are of the form "legacy translators", or
>> "RFC6145 was...".
> I don't think it's useful to refer in this doc to a spec that is already
> obsoleted.
> This is further reason why it's not useful to issue separate change
> docs. It gets confusing as to what you're arguing and why.
>>>> The document concludes that the translator should create IPv4 IDs rather
>>>>> than relying on atomic fragments as a source of that information (as per
>>>>> RFC2460) because there is no benefit, but are two reasons why this
>>>>> method is directly hazardous as well: 1) RFC 2460 does not require that
>>>>> the IPv6 ID field is generated to ensure that the low 16-bits are unique
>>>>> as required for use as IPv4 IDs as defined in RFC 6145, and 2) RFC 6145
>>>>> translation could result in collisions where two distinct IPv6
>>>>> destinations are translated into the same IPv4 address, such that IDs
>>>>> that might have been generated to be unique in the IPv6 context could
>>>>> end up colliding when used in the translated IPv4 context. I.e., this
>>>>> does not require ECMP as implied in Section 3.
>>>> mmm.. not sure I follow. When we refer to ECMP in Section 3 we're
>>>> actually describing the only possible scenario in which relying on the
>>>> ID in the Frag Header could be of use (i.e., possibly result in lower
>>>> collision rates).
>>> I'm not speaking of when the ID in the Frag Header can be useful. I'm
>>> speaking of other more likely cases where using the low 16 bits of the
>>> IPv6 ID field can generate IPv4 collisions.
>> So you argue in favor of adding an extra bullet noting that RFC2460 does
>> not require the lower 16 bits to be unique? (just double-checking). If
>> so, fine with me.
> Yes - specifically, 2460 does not require that the lower 16 bits of the
> ID are generated in a way that would comply with the expectations of
> using just those bits for IPv4.
>>>>> Minor issues:
>>>>> IMO, it remains unwise to continue to imply that networks should treat
>>>>> packets with fragment headers as an attack. Fragmentation support is
>>>>> critical to tunneling (see draft-ietf-intarea-tunnels) and we need to
>>>>> find ways to support their use safely. The text should be edited to
>>>>> explain that the primary motivation here is to avoid generating
>>>>> erroneous IPv4 ID fields, rather than to react to the incorrect
>>>>> classification of fragment headers as incompatible with the Internet.
>>>> Not sure what you mean.
>>>> We're not implying that packets employing FH are an attack. FWIW, I
>>>> don't personally think so. We do think that, when employing
>>>> fragmentation, you open the door to a number of attack vectors. See
>>>> e.g., Section 5 of draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt.
>>> Some of the attacks described are based on the widespread dropping of a
>>> valid IPv6 packet with valid IPv6 extension headers.
>>> IMO, it is important to be clear that this makes users of a legitimate
>>> IPv6 capability vulnerable because of incorrect behavior of routers. 
>> 1) The attack I referenced is just one possible attack. If you employ
>> fragmentation, an atacker could just send forged packets meant to cause
>> collisions of frag IDs such that your packets are dropped -- clearly
>> employing an extra feature (as in this case), creates an attack vector.
> There are many possible attacks but you focus on the one where routers
> drop packets because they have frag EHs.
>> 2) The bahavior in routers is a policy. We may not like it. BUt it's a
>> policy, not incorrect behavior.
> EHs are not optional in RFC2460. Dropping because you see them is not
> policy - it forces the router to fail to support a required feature of IPv6.
>>> It
>>> seems important to remind readers that the real issue here is the
>>> non-compliant routers. If that information isn't present, it implies
>>> that it is the use of the EHs that is incorrect and should be avoided in
>>> general. That's impossible for fragmentation - it is a critical
>>> capability without which tunneling cannot exist.
>> Fragmentation has been considered harmful for ages.
> And is finally being understood as fundamentally necessary for tunneling.
>>  And yes, we're
>> saying that if you *do not need it*, you shouldn't use it.
> Yes, if you don't need tunnels, you shouldn't use them either, but that
> doesn't mean tunnels shouldn't be used in general.
>>>>> The claim that links with IPv6 MTUs smaller than 1260 are rare needs to
>>>>> be supported with evidence. I appreciate that such evidence may be
>>>>> difficult to observe. In the absence of evidence, the statement should
>>>>> be more clear that there is no evidence to the contrary -- which is not
>>>>> the same as being able to claim that they *are* in fact rare.
>>>> I see your point. Any suggestion on how to tweak the text?
>>> It depends on what you know. AFAICT, we have no information on this
>>> issue. If that's the case, then the text should just state the impact on
>>> such links and say that "there is no evidence yet as to the prevalence
>>> of their use".
>> I'll talk to my co-authors about this one.
> AOK.
> Thanks,
> Joe