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

<mohamed.boucadair@orange.com> Mon, 29 April 2019 13:29 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 BCA8B12031B for <ipsec@ietfa.amsl.com>; Mon, 29 Apr 2019 06:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, 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 o-ngbEjlUIQU for <ipsec@ietfa.amsl.com>; Mon, 29 Apr 2019 06:28:59 -0700 (PDT)
Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3D4120319 for <ipsec@ietf.org>; Mon, 29 Apr 2019 06:28:58 -0700 (PDT)
Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 44t58n2sHtz101N; Mon, 29 Apr 2019 15:28:57 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 44t58n2D2MzDq83; Mon, 29 Apr 2019 15:28:57 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0439.000; Mon, 29 Apr 2019 15:28:57 +0200
From: mohamed.boucadair@orange.com
To: 'Tero Kivinen' <kivinen@iki.fi>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Topic: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
Thread-Index: AQHU9ID33HfUY8UNAEyhkEccw2niI6Y/2UGAgABdcfCAEv5wcA==
Date: Mon, 29 Apr 2019 13:28:56 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA673E4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <787AE7BB302AE849A7480A190F8B93302EA61B2A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA61B2A@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/A7m9lmSWK1nJNRz6AtGumcy7HoE>
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: Mon, 29 Apr 2019 13:29:01 -0000

Hi Tero, all,

I went with an updated version which takes into account the feedback from Valery. The updated version is available at: 
https://tools.ietf.org/html/draft-ietf-ipsecme-ipv6-ipv4-codes-03 

Can you please put this version in the WGLC? Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de
> mohamed.boucadair@orange.com
> Envoyé : mercredi 17 avril 2019 13:30
> À : Valery Smyslov; 'Tero Kivinen'; ipsec@ietf.org
> Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> 
> Hi Velery,
> 
> Works for me. Thanks.
> 
> Cheers,
> Med
> 
> > -----Message d'origine-----
> > De : IPsec [mailto:ipsec-bounces@ietf.org] De la part de Valery Smyslov
> > Envoyé : mercredi 17 avril 2019 09:48
> > À : 'Tero Kivinen'; ipsec@ietf.org
> > Objet : Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes
> >
> > Hi,
> >
> > I was thinking of another alternative design (well, it's a small
> modification
> > of a current one). Instead of defining IP4_ONLY_ALLOWED and
> IP6_ONLY_ALLOWED,
> > define IP4_ALLOWED and IP6_ALLOWED. The semantics would be a positive
> > assertion that this particular AF allowed, without any concerns with the
> > other AF.
> >
> > In this case, the behavior would be as follows:
> >
> > Requested @Init	Supported @Resp	Assigned 		Returned Notification
> >
> > IPv4			IPv6			None			IP6_ALLOWED
> >
> > IPv6			IPv6			IPv6			IP6_ALLOWED
> >
> > IPv6			IPv4			None			IP4_ALLOWED
> >
> > IPv4			IPv4			IPv4			IP4_ALLOWED
> >
> > IPv4 and IPv6	IPv6			IPv6			IP6_ALLOWED
> >
> > IPv4 and IPv6	IPv4			IPv4			IP4_ALLOWED
> >
> > IPv4 and IPv6	IPv6 or IPv4		IPv6 or IPv4		IP4_ALLOWED,
> > 			(Policy-based)				IP6_ALLOWED
> >
> > IPv4 and IPv6	IPv6 and IPv4	IPv6 and IPv4	IP4_ALLOWED,
> > 									IP6_ALLOWED
> >
> > An (mostly theoretical) advantage of this design is that if some new AF
> > appears
> > (well, I understand that it's unlikely in the foreseen future, but who
> > knows),
> > the design will work w/o changes, we only need to define a new <AF>_ALLOWED
> > notification.
> >
> > Regards,
> > Valery.
> >
> >
> > > 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 mailing list
> > > IPsec@ietf.org
> > > https://www.ietf.org/mailman/listinfo/ipsec
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec