Re: [bmwg] Suresh Krishnan's No Objection on draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07: (with COMMENT)

Marius Georgescu <> Thu, 08 June 2017 12:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EF70127333; Thu, 8 Jun 2017 05:01:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jFG_dGHPsUUC; Thu, 8 Jun 2017 05:01:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C0AFC127078; Thu, 8 Jun 2017 05:01:17 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 50E252832D1; Thu, 8 Jun 2017 15:01:16 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=MailProxy; t=1496923276; bh=/1JfWIowQG2H7xof+ir92czmkFswx+CafnVapUoPhcE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=a9S3trR+PSpknUjjAbyS0FsYJZ+1ZspBeFTYovbt3/EFUQL6vnTaoR5YV5jl1R4TA /zw7eUVCY5LBR8ajFD8l16vAfPlHIToC+UUE+jKsTfb3xdKcO1lHkNRIMqKTSvnJ0J lvAIhpsEriELWS96aTMYtvvpfEjuZ68YWAZYIH2M=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Marius Georgescu <>
In-Reply-To: <>
Date: Thu, 8 Jun 2017 15:01:13 +0300
Cc: The IESG <>,,,, Alfred C Morton <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Suresh Krishnan <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [bmwg] Suresh Krishnan's No Objection on draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Benchmarking Methodology Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Jun 2017 12:01:21 -0000

Hello Suresh,

Thank you for your review.
Please see my answers inline.
> On Jun 7, 2017, at 10:17 PM, Suresh Krishnan <> wrote:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-bmwg-ipv6-tran-tech-benchmarking-07: No Objection
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> * I am surprised that this document does not use (and does not even mention)
> the Well Known Prefix (64:ff9b::/96) for the algorithmic mapping between IPv4
> and IPv6 on translators as specified by RFC6052. Is there a reason why this is
> omitted?

Section 3.1 of RFC6052 states the following.

3.1.  Restrictions on the Use of the Well-Known Prefix

   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets.

Among the prefixes mentioned in Section 3 of RFC5735 is the IPv4 prefix reserved for benchmarking.
Keeping this is mind, I think using WKP for benchmarking  is not an option. 
We could note that a /96 from the prefix reserved for benchmarking (2001:2::/48) can be used . 

> * It is not clear from the document whether the time taken by the
> DNS64 resolution procedure is included in the latency measurements. It might be
> useful to note this.

We are not sure what you meant here. 
It might not be connected with your comment, but DNS64 is benchmarked separately from NAT64.
For NAT64, the latency benchmarks detailed in Section 7.2 are indeed recommended, but for DNS64 we proposed only the DNS resolution performance benchmark, detailed in Section 9.

Best regards,