IETF Logo Mail Archive

Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes

Paul Wouters <paul@nohats.ca> Tue, 30 April 2019 13:40 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B9F120075 for <ipsec@ietfa.amsl.com>; Tue, 30 Apr 2019 06:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxWy9h9IG8dS for <ipsec@ietfa.amsl.com>; Tue, 30 Apr 2019 06:39:59 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB94C12001B for <ipsec@ietf.org>; Tue, 30 Apr 2019 06:39:58 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44tjM01ccLzDpS; Tue, 30 Apr 2019 15:39:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1556631596; bh=T6MgkHwJL3sc5sooLGvkoT2+C77WZUQoPuuUMlahQWM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=YOg7MP0W7c2YMRGT3CUh93i9UdgEnTDMLG/ye8VIY93go7mFQgZuiCWQwS5/n4eUX hnNhMhUL8RJos/IJFgbo63Zevb4dNb9EKmFbSLSOtxelQ2kWDt6qqRFL7KaScSqLbE DYs86i9c0i97fggAxZXhEiu7FifG6MrTlqpZ1rJY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 3WC3IOCcFJ2Z; Tue, 30 Apr 2019 15:39:55 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 30 Apr 2019 15:39:54 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id DCFA73A3990; Tue, 30 Apr 2019 09:39:52 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DCFA73A3990
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D2D9340C121B; Tue, 30 Apr 2019 09:39:52 -0400 (EDT)
Date: Tue, 30 Apr 2019 09:39:52 -0400
From: Paul Wouters <paul@nohats.ca>
To: mohamed.boucadair@orange.com
cc: "ipsec@ietf.org" <ipsec@ietf.org>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA67B69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Message-ID: <alpine.LRH.2.21.1904300938050.17071@bofh.nohats.ca>
References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <787AE7BB302AE849A7480A190F8B93302EA67B69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/bA0yOwaqKfWPLs0RhvRkLxwXnL0>
Subject: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Apr 2019 13:40:01 -0000

On Tue, 30 Apr 2019, mohamed.boucadair@orange.com wrote:

> The responder does not know if the initiator is dual-stack or not. For example, an initiator can be instructed by policy to make use of separate requests.

Why would the initiator that is allowed by policy to do both v4 and v6
not ask for both at once?

I don't see the "use of separate requests" as a real use case. Can you
explain how this would actually happen in a real world?

Paul

v2.23.0 | Report a Bug | By Email