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

Tero Kivinen <kivinen@iki.fi> Tue, 16 April 2019 18:19 UTC

Return-Path: <kivinen@iki.fi>
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 2656612010C for <ipsec@ietfa.amsl.com>; Tue, 16 Apr 2019 11:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 d1k-7vfpDMHg for <ipsec@ietfa.amsl.com>; Tue, 16 Apr 2019 11:19:21 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 47FE3120096 for <ipsec@ietf.org>; Tue, 16 Apr 2019 11:19:20 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x3GIJFXR015812 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ipsec@ietf.org>; Tue, 16 Apr 2019 21:19:15 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x3GIJFxZ027131; Tue, 16 Apr 2019 21:19:15 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23734.7331.402882.289451@fireball.acr.fi>
Date: Tue, 16 Apr 2019 21:19:15 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: ipsec@ietf.org
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 14 min
X-Total-Time: 14 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/b7YbLH74MGQ0d1VNUEIlTS3MuGo>
Subject: [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, 16 Apr 2019 18:19:24 -0000

In the Prague meeting we had two options how to send information what
kind of address families are supported [1]:

1) IP6_ONLY_ALLOWED and IP4_ONLY_ALLOWED status notifications which
   are sent whenever only one address family is supported. I.e., if
   only one address family is supported, then IP*_ONLY_ALLOWED is
   sent. If both address families are supported, then no status code
   is sent. This is what current draft proposes.

2) ADDITINAL_ADDRESS_FAMILY_POSSIBLE status notification which is used
   when other address family than currently returned could also be
   used. I.e., if no address was assigned, then this status
   notification tells that trying with other address family works, and
   if address was assigned from one address family this tells that
   another request with another address family can also work. 

In the meeting we did not have clear concensus [2] on which of them
are better. The option 2 is closer to what we currently have in
RFC7296 for ADDITIONAL_TS_POSSIBLE.

Both of the options seems to work, and I think people think the
differences are so small, that they do not care. So unless people
object soon, I think we will keep whatever is in the draft, as I
seemed to be only one who thought the other option would be clearer.

[1] See slides 6 and 7 of
    https://datatracker.ietf.org/meeting/104/materials/slides-104-ipsecme-chair-slides-04
[2] https://datatracker.ietf.org/doc/minutes-104-ipsecme/
-- 
kivinen@iki.fi