[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
- [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Tero Kivinen
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Valery Smyslov
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes mohamed.boucadair
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes mohamed.boucadair
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Valery Smyslov
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes mohamed.boucadair
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes mohamed.boucadair
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes mohamed.boucadair
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Valery Smyslov
- Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Paul Wouters