Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06

Fred Baker <> Tue, 29 January 2019 23:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50B4213103F for <>; Tue, 29 Jan 2019 15:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 Ljg46yVoVc47 for <>; Tue, 29 Jan 2019 15:37:53 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A0561131031 for <>; Tue, 29 Jan 2019 15:37:52 -0800 (PST)
Received: by with SMTP id b14so17528344edt.6 for <>; Tue, 29 Jan 2019 15:37:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1vLJrbH1vZOMNaQlq/tSmP0HLrnp7F2DmviTwcmNY4Q=; b=BpMXErauL6GBy9qkHsqrd+Da4Dkv5NWsbQrEv8A/T2kkxsfOltFFt85U0kt/8R1B0O YYwR5iR/hBNsVTqm7L/9Ce2PdYgtlRvFrvshIL/3EFfi6JU7XeGkNQsByyCUZlUw70PV XuUgiAGPlMuboBo95pjjikmRRA0ifb1rXp6+oOG3ARrIAinRJ+OktWxFyokpQCRwaxay 2Omr33zQrNAexl6EJLZMrAfjf6LeRAXZcVApRDqn3jPrlhaH1/erznkn++3lzh54P0t/ 3uyEPRnDkStu1JLioh4Vy0zJAf3py8+ZFodPEAxECuW/z3B/YRbOpsaUlKHvCRqPpgMw 0qWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1vLJrbH1vZOMNaQlq/tSmP0HLrnp7F2DmviTwcmNY4Q=; b=LFQUb2V7vqwBFm6aLMlb6prUPsuVgrrzHohIvpKlA80K31gvmFOdqzq2zgzpYe8fyS 9HmOQyf6lWR1P56U9dn3PHAI6HkJAi19fc9+LlBIp345jUg0RCRN5pFRAdxM12JYk5F6 6jWO7xZqNXjBPhoBPsWZSgeAWb1fchEE120NiueeCyBeG/PsYbzPD/QcCZRtVf5D/qtV SmdXd/GX/sesEDrpB1yC6QnnlfOkdfHrN+J9qmArY9OutG0L944T2h60D8mKmLGIvTr1 vsJbjBDjBL4N02CtwVPPJAUDsoTx3zsHBRyZxz5KxPtuqjzeqVAJ1LtkYxvmj4dJ2AQi wIJw==
X-Gm-Message-State: AJcUukdutc+9KsQtsJBpC7rSrfqGVkKwRty/odqohACwkBJwMxG3bdNE 7iUFQHcoLeHO/w3P6xnr8tNJpGtV
X-Google-Smtp-Source: ALg8bN4CnTd3tM/woRZmu1N5ouw9+GoHuwh71PjORbTQ2o5HPShIsA9BaXQKYhVF7s3q9ygZdIsiQQ==
X-Received: by 2002:a17:906:364f:: with SMTP id r15mr9078960ejb.70.1548805071159; Tue, 29 Jan 2019 15:37:51 -0800 (PST)
Received: from ?IPv6:2600:8802:5600:164::14cf? ([2600:8802:5600:164::14cf]) by with ESMTPSA id h9sm57480ede.93.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 15:37:50 -0800 (PST)
From: Fred Baker <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_95833436-77CD-468F-B124-6B1D01EEDE7B"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.1\))
Date: Tue, 29 Jan 2019 15:37:46 -0800
In-Reply-To: <>
Cc: int-area <>
To: Tom Herbert <>
References: <>
X-Mailer: Apple Mail (2.3445.104.1)
Archived-At: <>
Subject: Re: [Int-area] Comments on draft-ietf-intarea-frag-fragile-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 Jan 2019 23:37:55 -0000

> On Jan 29, 2019, at 11:45 AM, Tom Herbert <> wrote:
> Hello,
> I have suggested text for the draft to address some previous comments
> made on the list.
> Last paragraph in section 4.3:
> "This problem does not occur in stateful firewalls or Network Address
> Translation (NAT) devices. Such devices maintain state so that they
> can afford identical treatment to each fragment that belongs to a
> packet.

Do we have a list of such products? I'm unaware of one. Making a blanket statement such as this troubles me, because it seems to say that this is invariably true, and I don't know that it is or isn't.

> Note, however, that stateful firewalls and NAT devices impose
> the external requirement that all packets of a flow and fragments of a
> packets for a flow must traverse the same stateful device; stateless
> devices do not force this requirement."

Here's an example of why blanket statements need to be qualified. If you take NPTv6 to be a form of NAT, it doesn't force route symmetry.

> Section 4.5:
> "IP fragmentation causes problems for some routers that support Equal
> Cost Multipath (ECMP). Many routers that support ECMP execute the
> algorithm described in Section 4.4 in order to perform flow based
> forwarding;

As far as I know, routers that hash fields in the IP header to select a en ECMP next hop do so because all packets in a flow will hash the same way (modulo the issues with the transport port number), not because they are doing per-flow forwarding. The do so explicitly to avoid having to maintain per-flow state and yet make all fragments of a message follow the same path.

> therefore, the exhibit they same problematic behaviors
> described in Section 4.4. In IPv6, the flow label may alternatively
> used as input to the algorithm as opposed to parsing the transport
> layer of packets to discern port numbers. The flow label should be
> consistently set for a packets of flow including fragments, such that
> a device does not need to parse packets beyond the IP header for the
> purposes of ECMP."
> Add to section 7.3:
> "Routers SHOULD use IPv6 flow label for ECMP routing as described in [RFC6438]."
> _______________________________________________
> Int-area mailing list

Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu